天下事皆雷同

一个朋友移民到了澳洲，在那里的一个 软件 公司做了4 年，回来休假 的时候我们做了两 次交流，第一次2 小时，第二次 4 小时 。在 成都的夜色 下 狮子山边的一个烧烤店， 我们 就着 烧烤和 啤酒 ， 谈到软件开发问题和方法，感觉获益匪浅。他 所在的 公司大约有200 多人， 公司主要 做银行理财软件，大约有10 年历史，并且占有澳洲这个领域市场份额的 50% ，他们的软件的历史大约也有 10 年了。说起来，一个 10 年的软件，如同一个老房子，如果不经常的做些修修补补，就会很快的烂下去 。 听起来他们也遇到了类似的问题 ， 并且看起来还很严重。

 

给他印象最深的是他们的主执行文件有 80M 的 exe （实在说，我难以想象怎么会这么大，因此疑问重重的确认了 3 次，但是他确定的给我说，就是这个大小）， 并且也谈及了软件存在的主要问题 ：

 

1.  软件 内有几千个 F orm，都是控件摆上去，然后双击编写代码，连按钮名称和事件名称都不改，都是 Button1Click 之类的。 这意味着，要找到相应的事件代码，必须先打开Form ，从 Form 上点击得到对应的事件，而不能直接在代码中找到要修改的代码。

2. 访问数据库的方法也不集中，比如有的代码用 ADO ，有的用 BDE ，还有什么直接开表的 （ 后面的这个没有太听明白 ） 。

3. 有很多控件，比如 ReportBuilder  ， Formula One 之类的。甚至同样功能的控件都有几个，用于不同的地方。 他们无一例外的没有做任何封装。这意味着，同样的功能，需要掌握不同的知识。

4. 还需要做 Office ， OutLook 等外部软件的接口。

5. 很多代码都不太看得懂，很多文件都有 1 万多行。有些是数库访问代码依赖于逻辑代码和 UI 代码（不知道怎么依赖的） 。大量的代码，给理解软件模块带来了很多的麻烦。

反正，最后的效果就是80M 的 EXE 文件 。

 

这个公司也开始意识到这个问题，逐步的开始改进，还请了一个很牛的家伙，付了不少的咨询费用，经过改造，可以让项目每一个月发一次版本（我确认了下，就是Scrum  方法，我们曾经就这个方面，邀请讲师来公司交流过）；而有些老的代码都不想看，就逐步的自己编写一次，换掉整个模块，容易把控 件 理解。可是这样做的风险也不小，还不知道如何处理。如果不能良好的组织模块，建立接口，没有利用抽象和分解这些老的技术，必然 存在 问题 ” 。

对此，我建议他可以试试重构技术，并且推荐了Martin Folwer 的《重构：改善既有代码的设计》的书籍给他。我的

建议如下：

1. 老的代码修改起来确实很有难度，但是可以一点点的去用质量更高的代码去蚕食目前不良的代码，哪怕一次就做一个函数，慢慢的做，也许需要几年的时间 ，但是收效也是很明显的。

2. 确立标准。先做简单的，比如化曲为直，分解函数可以先做 ， 复杂的放到后面。

3. 先捡软柿子捏。从一次不超过一个小时的重构开始，逐步的熟练和更加清楚原来的业务模式后， 再 把大问题分解 为 小问题，把其中不超过一小时的重构做了；反正超过一小时的尽量不做，直到大家都觉得有信心后，再动大的。千万要注意，问题存在不一定要马上解决，问题唯有分解到一个个的可执行的步骤，才能真 正 的去解决它。比如架构问题，数据库结构的问题，就是很难分解下去的问题，这样的问题，就一定要先放下，等到重构做的比较多，代码良性程度高的时候，自然就是时机渐渐成熟的时候，就可以动了。

4. 做好保护措施。比如采用 TDD 开发（测试驱动开发）模式；如果觉得 TDD 不习惯或者不好着手，那么至少要利用好版本管理工具，让代码可逆，以便在重构看起来不太可能成功的情况下，回溯到前一个版本。我就遇到这样的情况 ： 以为是一个很小的，有价值的重构，但是做的过程中发现关联很多，耗时很多，并且有改错功能的危险，必须重新评估，于是利用版本管理工具回溯 ， 重头再来。还好这样的情况我只遇到了一次。估计一个重构的规模大部分情况比较容易，有少数情况比想象的要复杂的多，因此必须保证，我们能够 “ 回得来 ” 。

5. 在重构时，反正功能都是不去动的，因此不会担心功能上不够，可以利用零星的时间，或者专门的时间去做。

由于实际做的时候，有这么多的决策点，因此我建议他先找到合适的团队，这个团队必须有足够的意愿 去 尝试 ，或者可以通过沟通和培训达到这样的意愿，在过程中积累方法。 这个技术不容易衡量，同样的重构，重构条目少的可能花费更多的时间， 条目 多的反而花费时间不多，很多效果也存在于人心之内， 单纯 从文档上看是看不出来的 ，因此意愿是第一位的。 只要一个团队获得成功，取得了过程中的经验和感受，随后就要容易多了。

奖励是可以 配套 考虑的 。 重构本身的成果不易衡量，很多时候是感受和经验，并且存在于人心内，因此奖励本身不能仅仅用来奖励结果，而是重在奖励意愿；凡是主动的承担，积极的沟通，摸索更好的模式，尝试更好的技术，并且让这些能够共享，用于支持其他项目组的重构的，都可以考虑奖励。奖励本身无法分出等级，因此是表明管理者重视技术对产品的支撑能力，表明在这个方面的积极态度，对大家的稳重的尝试给予肯定。故此，凡是不愿意做的，一段时间内，都可不必勉强。我也给他介绍了我们的情况，我们有两个组开始利用重构来改善代码，有3 个人（仅仅限于我听说过的）以前独立的做过几次重构，目前看来效果都还不错。他决定回去马上就去试试，并和我  Email  交流。

尽管程度不同，这个公司和我们有某些类似的地方， 尤其是代码的历史久远，问题众多， 因此方法也值得我们借鉴。