重构如复盘

这篇blog算是之前关于重构的一个总结，导火索是上周花了不少时间把前一段写的一个功能模块做的一个重构。

事实

没做之前，功能什么的基本都对，有一些小bug和效率不是很好，问题最大的是我感觉这部分有点失控，心里一种乱的不安全感，这个感觉很差。

另外就是在处理bug，增加新的功能和用其他方案做优化的时候，可以说是举步维艰，不仅是效率很慢，情绪上很抵触。

花了大约3到4个工作日做的重构，完成之后前面列的问题荡然无存，还顺便修了很多bug和性能问题，更重要的是这几天在做更清晰的设计和简洁的编程，除了很享受的感觉外，还得到了不少的思考和提高。

后续开发的速度，源自结构的优化和情绪的变好，提升大约有%50--%80（原来是%30到%50，但我实际测下来是这个数字）。

“重构是有好处的”这是废话，关键是重构的意义到底多重要。是不那么重要的，有时间才能做（实际是项目忙起来，这种认识下的重构就永远不会有时间做），还是会非常重要，必须成为一个task的必然组成部分？

做到现在，我的观点是：重构是仅次于实现前的设计的一个阶段，必须成为每一个task的必要组成部分，做到90分在收场。

重构如同复盘

玩RTS和棋类游戏的人都知道复盘的重要性，那是一段纯粹的，安静的思考总结的时间，也是一段自我提高非常快速的时间。

重构也是如此，是一段可以好好思考和沉淀合理的设计和简洁的coding的时期，同时可以好好指导自己下一次的task的完成。

在实际项目中，重构过程一般发生在功能都完成的差不多，有零星bug和performance问题的情况下，心情也相对放松平静，客观上，重构阶段也适合思考和沉淀。

所以在长期看来，在重构的过程好好思考，总结以及二次设计和实现，会受益很多。

(2011.8.10)

实际上我对只设计不编码的人也感到颇为奇怪，或许我的境界没到，但是这样真的可以么？编码结束之后才能进一步去复盘，去提升设计和编程能力，单纯的设计也就是设计了，如何去检验呢？等待编程人员的反馈么？

优雅设计与实现比率最高的阶段

无论是读大师的事迹也好，还是自己的实践，所谓优雅的设计和实现是可以达到的，但是根据资质，需要不同程度的练习。

这里的练习就是指，你需要去实际的做出很多优雅的设计和实现，以至于习惯于此，那么也就是一个程序员拥有了这样的能力。

而在限时探索性模块实现过程中，做到优雅设计与实现的确是比较难的，但是在重构时候就自然而然了，这个可以说是一个黄金的做优雅设计和实现的阶段。

这个就像星际2中大规模部队交锋，奋战了20分钟之后，终于迎来了20秒的决战时间，可以好好锻炼对抗性大规模部队交锋，怎可不好好珍惜？

CleanCode Rocks

最终写出很简洁的代码就像打篮球时候灌篮，投了3分，漂亮的过人，盖了个大帽。。。

这种乐趣大于取胜，是我们的原动力。

clean code也是一样，那是一种让你全身欣喜的事情，让你更爱编程的事情，回家的路上，回想一天的工作，会跟自己说，这tmd才是我想做的。

重构会大幅度加速后续开发速度，提升开发质量，降低消耗

这个是实际编程的时候才会切实感受到的东西， 实际编程中，后续开发中面对一份简洁的代码和乱的代码一个最大区别是，简洁代码下无需费多余力气，很自然的就写的简洁清晰，人也处于一个非常舒服的状态，一天编程下来是欣喜的感觉，这像是在重构过程中建立的优雅规则和心态的延续。

而面对糟糕代码时候，心里就很乱，脑力劳动受心情影响非常大，这一点就差狠多了。而且你完全无法写的简洁优雅，因为代码中已经是缺乏了头绪，在大面上已经乱的前提下，后续的开发就是没法做到这一点。而且进一步如果大家开始习惯这样，这个是非常危险的，就像公司里出现了不好的习气，凌乱开始蔓延，熵是默认增加的，需要额外的力量来对抗它。从之前的项目来看，这种凌乱会像慢性疾病一样，逐渐积累，可能杀掉一个项目，可能只是让项目受伤，最后只是剩下“如果我们当初xxxx，就xxx“的哀叹了。

我认为生产力的提升有%50到%80。

当然，道理也是有条件才成立的，在后续开发还有比较长的时期的情况下，就毫不犹豫的去做这个事情。

如果已经后期了，那么就值得商榷了。

做到90分收场

这里想说这么几个意思：

1，90分：60分可以说是功能可以用，时不时的crash，出点bug，效率不太好，80分是当下crash，bug，性能问题都没有了，外在来看是可以支持游戏上市的程度，90分是在这个阶段上在进一步，结构更加合理，实现更加简洁，文档也比较齐全，成为后续开发的标准与强心剂，而不是反例和绊脚石。

2，收场：也就是在完成进入下一个task之前，要把重构工作做好，因为这是最佳做重构的时间，所有东西都在脑袋里，做起来效率高，不会遗漏。完成的模块坚实，自己心里也踏实和清爽。这里有踏踏实实一步一个脚印的意思，也有get things done以解放自己脑力和精神力的意思。

而之前的经验是，虽然说完成到差不多那里，感觉好像是做了很明智的决定，不多不少，但是实际下来，隐藏的问题总是会暴露出来，使你付出比干脆弄好大得多的代价。

具体问题具体分析+尽量不妥协

是的，这都太理想化了，实际有挑战的开发经历过会知道，任务列表都快拉到下辈子了，这时候很多人的压力也比较大。

冲刺型的开发模式，减免了很多包括重构的科学的开发方式，就如同星际二兵临城下时候，为了缓解压力拉了农民去迎战，短时间的压力得到解决，长期则给自己带来了很大麻烦。

当然兵力相差很大的极限情况，必须如此。

需要做的是拼命压低自己的妥协底线，当然这个也不是随便说说的，需要更集中的精力以提高效率，更多的加班以延长时间，但这个是值得的。