火箭发射是一件相当隆重的大事，
需要经过长时间的准备，花费不计其数的人力物力后，
在一个精心选择的时间，所有相关人物齐聚一堂，等待火箭的轰然升空。

最大的问题是，火箭发射可能失败，在付出巨大的努力后，依然失败。

个中的情形与后果，与软件开发中的一次性重构非常相似。

一次性重构是软件开发中一种相当具有冒险精神的活动，
需要实施者有“不成功便成人”的坚毅决心，埋头苦干若干日子，
最后在合十祈祷中，迎来一个充满不确定因素的发布。
用Bison的话来说，是找死。

找死也有两种找法，
一种是终止老版本，不接新需求，专心闭门造车，重写一个新版本；
还有一种是同时维护两个版本，老版本做新需求，等新版本做出来之后，再把新功能合并过去。
前一种伴随着巨大的风险，而后一种则会带来太多额外的复杂性，都不是一个理性程序员的选择。

更好的方式是采用平滑重构，这才是真正意义上的重构。
只要不是病入膏肓，这是最佳选择。

由此想到一个不太恰当的比喻：将编写程序比喻为治理国家。

假如现在的执政党已经日益腐朽，人浮于事，贪污横行。
总之，是到了需要改革（重构）的时候了。
此时有两个选择：革命，或者重新大选。
先不论大选的利弊，单看革命。
另一股势力，利用民众的不满，积极宣称自己的主义可以拯救这个岌岌可危的国家；
由于拥戴者渐多，力量日益强大，终于到了可以和执政者分庭抗礼的程度。
执政者当然不会轻易交出自己手中的权力，
于是经过非常暴力或者不太暴力（没有非暴力这个选择）的斗争，
新势力终于推翻了旧势力，春风得意的上台了。
一时间，气象一新，处处欣欣向荣的美好景象。
经过若干年后，执政党开始日益腐朽，人浮于事，贪污横行。
又一个轮回开始了⋯⋯

这种情形，历史上还少见吗？
软件终究会腐朽的，就像政党一样。
与其暴风骤雨，我宁可润物无声。

培训的题目是《边重构边生活》，讲师Bison，讲得非常不错。
本身对行业和实践有深入的认识，关键是可以将想法有条理的表达出来。
如果可以讲得更加生动，将是一个非常棒的课程。
对“火箭发射”的例子印象深刻。
做了详细的笔记。
其实生活中很多例子都是相通的。

相比较而言，另一门《set模型》讲得就逊色很多。