重构-卓越程序员修炼之道培训总结(一)

【重构】老问题总是拿出来说，翻来复去，但是老问题，你每次去翻的时候总会发现新的亮点，新的问题。

就像：
很多人看了《重构：改善既有代码的设计》，却没有理解；
很多人理解了却没有去做；
很多人做了却没有做好；

why?

请大家跟着我再理解下【重构】这个旧得不能再老的新问题
本人会每天培训完回来整理【重构】的思想，实践和总结
在这里不管帖子写得怎么样，请大家支持我，谢谢

【重构】
1、重构是什么？
2、怎么去重构？
3、何时去重构？
3、重构的原则是什么?
等等，这些概念的东西请大家先去熟悉下《重构：改善既有代码的设计》

【重构】==【看病】
1、程序员==医生
2、臭代码==病

Q：这样的等式成立吗？
A：成立
Q：why?
A：医生给病人看病，先了解病人的病情，大概什么情况，哪个部位不舒服啊，怎么个不舒服法，或是去拍个照片B超化验之类的，结果出来了，然后确诊，【一般经验的医生】大概什么病，开个药方子完事，你过些天再来复查一下，这可为病情跟踪啊，【有经验的医生】这个是什么病，病情怎么样，你要注意些什么，开个药方子完事，有事过几天来复查，没事就完事。
A：程序员，首先查找臭代码，分析臭代码上下文整体情况，确定后进行重构，重构后模块化测试，集成测试，上线，最后跟踪，这和医生看病一个道理。

结论：程序员就是臭代码的医生，重构就是看病

什么是【臭代码】？
臭代码自然有代码的坏味道，它是指在代码之中潜在的问题的警示信号，或者潜在的问题，或是潜在的缺陷，并且是需要重构的症状。
臭代码也是自然界一种产物，提供面向对象的分析，包括：症状（有助于找出问题的线索），原因（对问题如何产生的说明），措施（可能需要的重构），成果（在哪些方面得到了收益）。

1、症状
《重构：改善既有代码的设计》中提过21种代码坏味道
-重复代码
-过长方法
-过长类
-过长参数
-注释过多
-临时字段
- 数据泥团
-过度偶合
-冗余类
。。。。。。还有很多

2、原因
概念：是谁把代码变臭了？客户？老板？

- 有的时候，我们会把原因归咎于客户，责怪他们总是改变需求，我们自我安慰地认为，只要客户的需求仅限于他们最初所声明的，那么我们的设计就是没有问题的，所以错就错在客户三天二头的改变他们的需求

-有的时候，我们也会埋怨老板，是他没有给我们时间，进行充分分析，其实根本不存在充分分析这种东西，无论花费多少时间试图去找出完美的软件结构，客户总是引入一个需求变化破坏这个结构，不存在完美结构，只存在哪些试图平衡当前的代价和收益的结构

走开下
------------------------------------------------------------------------------------------------------------------------
在当下，软件整个开发周期中为什么维护周期往往是最长的，为什么？
因为软件开发太注重设计，或是过渡设计，导致比较忽略编码环节
设计是软件开发的关键环节，而把编码看做机械式低级劳动，设计就像画工程图纸而编码就像施工一样
设计由设计师负责，编码由施工人员负责，就像造房子，有图纸随便叫个农民工施工就可以了
但是这是错误的！！！！
因为软件的可塑性更强，而且完全是思想产品

虽然一些项目中，设计也许可能会很详细，并且详细能够让编码工作近乎机械化，但很少有如些完整的设计。
那么需求的变更，原先的设计不再适合，那么【源代码就是设计】
------------------------------------------------------------------------------------------------------------------------

结论：是谁把代码变臭了？编码（程序员）

为什么程序员会把代码变臭呢？
a、破窗效应
-是关于环境对人们心理造成暗示性或诱导性影响的一种认识
比如：一个很干净的地方，人们会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人们自然会随手扔下去，这就是破窗效应
简而言之，好的代码会促生好的代码，糟糕的代码会促生糟糕的代码，不要低估了这种惯性思想，没有人想去整理糟糕的代码，同样也没有人想去把完美的代码弄得一团糟。

b、技术债务
【无间道】有句话，“出来混，总有一天是要还的”
-每每开发团队在设计或架构时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，这就是开发团队所欠下的债务，最后还的时候需要支付利息
-短期效应带来的往往是跟不上需求变化，程序员就开始埋怨客户需求变态，埋怨老板时间给得太少
-新来的总是埋怨老的，妈了个比的，这是什么代码，但是新来的新代码还是延续老代码的臭味道，本金加利息一直在累加

3、措施
我们重回主题【重构】
-重构，让代码简单易读
-重构，让代码可维护性
- 重构，让代码易于测试

而优秀的代码就需要不断的重构，不断的重构，不断的重构
-实现之道
-遵守敏捷实践去发现/诊断问题
- 应用设计原则去解决问题
-应用适当的原则和模式去解决问题，重构到优秀代码

原则：不是先写臭代码再重构，而是写代码==重构

实现：   期待培训二三四（待续。。。）
A、函数重构
B、类重构
C、设计与重构
D、函数（类）命名，格式，注释重构
E、重构名录
F、架构重构

4、成果
-代码简单易读
-代码易于维护
-减少破窗效应
-减少技术债务

总结：
第一天培训，是让人兴奋的，受教的，让我的重构认识更深层，更彻底
决定培训完后，写个PPT，回公司给同事演讲，这也是来的目的，并且可以再让自己加深印象
二个多小时，好累啊，好累啊，我的腰。。。

期待培训总结二三四，待续。。。

谢谢JEer 们支持

评论

18 楼 黑暗浪子 2010-12-02  

select*from爱 写道

黑暗浪子 写道

kinglyhum 写道

谈谈个人看法，以求抛砖引玉
理论上：

团队有重构的环境，有以下几点：
1.项目经理要对项目有十足的掌控，并且一定要能顶住来自各方面的关于项目的压力，这点最重要，如果这一条件不能满足，其他全是浮云
2.项目要保证持续集成，有经验人员的Code Review,及时发现设计和编码的问题，做出调整
3.程序人员的自律，重构应该是一种习惯。对于自己的代码，应该不断的优化，力争实现最好的设计和最优的性能。但有一点，必须保证项目进度。客户是不会关系你代码是否整洁漂亮的。

实际上：
1.项目进度优先，往往因为时间紧张（正常的开发工作尚且需要加班），重构被放在末位甚至不予考虑，一些必要的流程被忽略，一切以“实现功能，完成项目”为导向，小公司尤甚
2.开发人员对自己写的代码不负责，见过写完功能自己都没调通的人高喊“做完了”，结果可想而知，说白了是职业素养问题
3.销售手腕。对于某些需要优化或是添加的功能，其实可以再和客户沟通然后作为新的功能点开发，再产生利润，这方面我也是最近才看到，对于不太懂软件的客户尤其有效，的确大开眼界。

另外请LZ改善排版，照顾一下楼下的童鞋

这个行业越来越良莠不齐。像这种高喊“做完了”的人，一旦被我查出来，基本上绩效考核就要扣分了。如果屡次三番不肯改正的，基本上就是被边缘化和扫地出门的命运。行业需要优胜劣汰，不是你进了这个行业就可以一劳永逸的。

这种人我遇到过.我改结束的那个项目就是那种人做的,
做为项目组长,
在他离职后:
1.(当时这个项目以及做了一年).他的项目成员没有一个人能从头到尾的走一遍流程,
2.文档一大堆,不过都是乱写的,看了也没用,更离谱的是部分功能不解释
3.项目有头到尾鲜有注释
4.莫名其妙的变量命名规则:比如:元件库管理  -- string yjkManage; (yjk为元件库的拼音缩写)

更加无语的是,

引用

try{
  //do something
}catch(excption e){
   msgbox('恭喜,操作成功')
}finally{
msgbox('恭喜,操作成功')
}

以及大量使用goto 和标签(.net代码,这里是用java做个比喻)
然后,这个人去了用友总部,,,为用友默哀...

做。net的人大多数都不太注重clean code。所以我一直不太瞧的起他们。当然牛人也有的，但是比做java的少很多了。
另外说一句，用友公司也就靠着中央关系搞的好，他们的管理，技术，售前售后，实施都很混乱。所以我也一向瞧不起他们。
不过yjk太喜感了，明显是个英语没学好的朋友。哈哈，编程语言都是以英语为基础的，这个学不好，编程水平也高不到哪里去。

17 楼 黑暗浪子 2010-12-02  

<div class="quote_title">johnson_liu 写道</div>
<div class="quote_div">
<div class="quote_title">superheizai 写道</div>
<div class="quote_div">
<div class="quote_title">jwinder 写道</div>
<div class="quote_div">
<p>-新来的总是埋怨老的，妈了个比的，这是什么代码，但是新来的新代码还是延续老代码的臭味道，本金加利息一直在累加</p>
</div>
<p>正在做这个事情。其实，不敢重构也是原因的，代码不是我写的，而且不懂大多数的逻辑和代码引用关系，而且，系统已经在正常运行中，如果你维护出了问题，就是你的责任。虽然说，有点怕承担责任，可是，对于我现在的企业来说，代码能不动就不动，除非是我自己新添加的。</p>
</div>
<p>同样的问题啊，其实不是说我们自己不想动，自己对着这烂代码开发也头疼啊，其实这是能不能动，能否把握的问题还有就是时间进度的问题~</p>
</div>
<p>其实如果花点时间还掉点技术债务，后面绝对能省一大笔时间。但是现在一个人战斗的项目几乎没有，因此团队内部的代码标准还是要重点强调的。还有就是没有人能保证自己修改烂代码后的代码是不烂的，万一出问题，这个绝对要负责任的。所以很多人为了避免麻烦，都不太愿意改烂代码，反而在这种代码上再写自己的代码。这个就很难说了。</p>

16 楼 johnson_liu 2010-12-02  

<div class="quote_title">superheizai 写道</div>
<div class="quote_div">
<div class="quote_title">jwinder 写道</div>
<div class="quote_div">
<p>-新来的总是埋怨老的，妈了个比的，这是什么代码，但是新来的新代码还是延续老代码的臭味道，本金加利息一直在累加</p>
</div>
<p>正在做这个事情。其实，不敢重构也是原因的，代码不是我写的，而且不懂大多数的逻辑和代码引用关系，而且，系统已经在正常运行中，如果你维护出了问题，就是你的责任。虽然说，有点怕承担责任，可是，对于我现在的企业来说，代码能不动就不动，除非是我自己新添加的。</p>
</div>
<p>同样的问题啊，其实不是说我们自己不想动，自己对着这烂代码开发也头疼啊，其实这是能不能动，能否把握的问题还有就是时间进度的问题~</p>

15 楼 jwinder 2010-12-02  

rmn190 写道

以设计模式指导重构，以重构反思设计模式的重要性。

新来的同事，还很少懂得设计模式和重构这一个过程，但是可以教会他不要写坏味道的代码，至少，代码要看起来整洁

14 楼 jwinder 2010-12-02  

kinglyhum 写道

谈谈个人看法，以求抛砖引玉
理论上：

团队有重构的环境，有以下几点：
1.项目经理要对项目有十足的掌控，并且一定要能顶住来自各方面的关于项目的压力，这点最重要，如果这一条件不能满足，其他全是浮云
2.项目要保证持续集成，有经验人员的Code Review,及时发现设计和编码的问题，做出调整
3.程序人员的自律，重构应该是一种习惯。对于自己的代码，应该不断的优化，力争实现最好的设计和最优的性能。但有一点，必须保证项目进度。客户是不会关系你代码是否整洁漂亮的。

实际上：
1.项目进度优先，往往因为时间紧张（正常的开发工作尚且需要加班），重构被放在末位甚至不予考虑，一些必要的流程被忽略，一切以“实现功能，完成项目”为导向，小公司尤甚
2.开发人员对自己写的代码不负责，见过写完功能自己都没调通的人高喊“做完了”，结果可想而知，说白了是职业素养问题
3.销售手腕。对于某些需要优化或是添加的功能，其实可以再和客户沟通然后作为新的功能点开发，再产生利润，这方面我也是最近才看到，对于不太懂软件的客户尤其有效，的确大开眼界。

kinglyhum兄弟，你说得很对，最主要的是程序员的认识和修养问题

13 楼 jwinder 2010-12-02  

抛出异常的爱 写道

ltian 写道

重构很重要！应该重构，问题是，重构需要花钱！老板不同意！

改bug也需要花钱,
老板同不同意不是问题.

抛出异常的爱大哥，说得很对，BUG修改的时间和花的钱往往比重构花的人力和钱，多得多，因为你修改一个BUG后往往产生2，3，4或更多的BUG，质量跟不上去，BUG永远加陪的多起来

12 楼 jwinder 2010-12-02  

sambean 写道

期待后续章节

JEer们，我来了，在这里惭愧的和大家道个谦，没有及时更新，新版本
主要这几天晚上也在忙，所以一直没有写

再过些天，我会给公司的同事讲这些，然后再总结写以下2，3，4版本

也会把我的PPT放上来，谢谢支持，我会为JEer们努力的，有你们在，我很开心

11 楼 select*from爱 2010-12-01  

黑暗浪子 写道

kinglyhum 写道

谈谈个人看法，以求抛砖引玉
理论上：

团队有重构的环境，有以下几点：
1.项目经理要对项目有十足的掌控，并且一定要能顶住来自各方面的关于项目的压力，这点最重要，如果这一条件不能满足，其他全是浮云
2.项目要保证持续集成，有经验人员的Code Review,及时发现设计和编码的问题，做出调整
3.程序人员的自律，重构应该是一种习惯。对于自己的代码，应该不断的优化，力争实现最好的设计和最优的性能。但有一点，必须保证项目进度。客户是不会关系你代码是否整洁漂亮的。

实际上：
1.项目进度优先，往往因为时间紧张（正常的开发工作尚且需要加班），重构被放在末位甚至不予考虑，一些必要的流程被忽略，一切以“实现功能，完成项目”为导向，小公司尤甚
2.开发人员对自己写的代码不负责，见过写完功能自己都没调通的人高喊“做完了”，结果可想而知，说白了是职业素养问题
3.销售手腕。对于某些需要优化或是添加的功能，其实可以再和客户沟通然后作为新的功能点开发，再产生利润，这方面我也是最近才看到，对于不太懂软件的客户尤其有效，的确大开眼界。

另外请LZ改善排版，照顾一下楼下的童鞋

这个行业越来越良莠不齐。像这种高喊“做完了”的人，一旦被我查出来，基本上绩效考核就要扣分了。如果屡次三番不肯改正的，基本上就是被边缘化和扫地出门的命运。行业需要优胜劣汰，不是你进了这个行业就可以一劳永逸的。

这种人我遇到过.我改结束的那个项目就是那种人做的,
做为项目组长,
在他离职后:
1.(当时这个项目以及做了一年).他的项目成员没有一个人能从头到尾的走一遍流程,
2.文档一大堆,不过都是乱写的,看了也没用,更离谱的是部分功能不解释
3.项目有头到尾鲜有注释
4.莫名其妙的变量命名规则:比如:元件库管理  -- string yjkManage; (yjk为元件库的拼音缩写)

更加无语的是,

引用

try{
  //do something
}catch(excption e){
   msgbox('恭喜,操作成功')
}finally{
msgbox('恭喜,操作成功')
}

以及大量使用goto 和标签(.net代码,这里是用java做个比喻)
然后,这个人去了用友总部,,,为用友默哀...

10 楼 grady 2010-11-30  

支持，期待下文

9 楼 xiarilian12 2010-11-30  

写的很好，确实是这样。。。
支持了

8 楼 rmn190 2010-11-30  

以设计模式指导重构，以重构反思设计模式的重要性。

7 楼 黑暗浪子 2010-11-29  

kinglyhum 写道

谈谈个人看法，以求抛砖引玉
理论上：

团队有重构的环境，有以下几点：
1.项目经理要对项目有十足的掌控，并且一定要能顶住来自各方面的关于项目的压力，这点最重要，如果这一条件不能满足，其他全是浮云
2.项目要保证持续集成，有经验人员的Code Review,及时发现设计和编码的问题，做出调整
3.程序人员的自律，重构应该是一种习惯。对于自己的代码，应该不断的优化，力争实现最好的设计和最优的性能。但有一点，必须保证项目进度。客户是不会关系你代码是否整洁漂亮的。

实际上：
1.项目进度优先，往往因为时间紧张（正常的开发工作尚且需要加班），重构被放在末位甚至不予考虑，一些必要的流程被忽略，一切以“实现功能，完成项目”为导向，小公司尤甚
2.开发人员对自己写的代码不负责，见过写完功能自己都没调通的人高喊“做完了”，结果可想而知，说白了是职业素养问题
3.销售手腕。对于某些需要优化或是添加的功能，其实可以再和客户沟通然后作为新的功能点开发，再产生利润，这方面我也是最近才看到，对于不太懂软件的客户尤其有效，的确大开眼界。

另外请LZ改善排版，照顾一下楼下的童鞋

这个行业越来越良莠不齐。像这种高喊“做完了”的人，一旦被我查出来，基本上绩效考核就要扣分了。如果屡次三番不肯改正的，基本上就是被边缘化和扫地出门的命运。行业需要优胜劣汰，不是你进了这个行业就可以一劳永逸的。

6 楼 superheizai 2010-11-29  

<div class="quote_title">jwinder 写道</div>
<div class="quote_div">
<p>-新来的总是埋怨老的，妈了个比的，这是什么代码，但是新来的新代码还是延续老代码的臭味道，本金加利息一直在累加<br></p>
</div>
<p>正在做这个事情。其实，不敢重构也是原因的，代码不是我写的，而且不懂大多数的逻辑和代码引用关系，而且，系统已经在正常运行中，如果你维护出了问题，就是你的责任。虽然说，有点怕承担责任，可是，对于我现在的企业来说，代码能不动就不动，除非是我自己新添加的。</p>

5 楼 kinglyhum 2010-11-29  

谈谈个人看法，以求抛砖引玉
理论上：

团队有重构的环境，有以下几点：
1.项目经理要对项目有十足的掌控，并且一定要能顶住来自各方面的关于项目的压力，这点最重要，如果这一条件不能满足，其他全是浮云
2.项目要保证持续集成，有经验人员的Code Review,及时发现设计和编码的问题，做出调整
3.程序人员的自律，重构应该是一种习惯。对于自己的代码，应该不断的优化，力争实现最好的设计和最优的性能。但有一点，必须保证项目进度。客户是不会关系你代码是否整洁漂亮的。

实际上：
1.项目进度优先，往往因为时间紧张（正常的开发工作尚且需要加班），重构被放在末位甚至不予考虑，一些必要的流程被忽略，一切以“实现功能，完成项目”为导向，小公司尤甚
2.开发人员对自己写的代码不负责，见过写完功能自己都没调通的人高喊“做完了”，结果可想而知，说白了是职业素养问题
3.销售手腕。对于某些需要优化或是添加的功能，其实可以再和客户沟通然后作为新的功能点开发，再产生利润，这方面我也是最近才看到，对于不太懂软件的客户尤其有效，的确大开眼界。

4 楼 抛出异常的爱 2010-11-29  

ltian 写道

重构很重要！应该重构，问题是，重构需要花钱！老板不同意！

改bug也需要花钱,
老板同不同意不是问题.

3 楼 ltian 2010-11-29  

重构很重要！应该重构，问题是，重构需要花钱！老板不同意！

2 楼 gdwrx_winson 2010-11-29  

重构很重要！

1 楼 sambean 2010-11-29  

期待后续章节