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

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

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

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 们支持