天下事皆雷同
一个朋友移民到了澳洲，在那里的一个软件公司做了4年，回来休假的时候我们做了两次交流，第一次2小时，第二次4小时。在成都的夜色下狮子山边的一个烧烤店，我们就着烧烤和啤酒，谈到软件开发问题和方法，感觉获益匪浅。他所在的公司大约有200多人，公司主要做银行理财软件，大约有10年历史，并且占有澳洲这个领域市场份额的50%，他们的软件的历史大约也有10年了。说起来，一个10年的软件，如同一个老房子，如果不经常的做些修修补补，就会很快的烂下去。听起来他们也遇到了类似的问题，并且看起来还很严重。
?
给他印象最深的是他们的主执行文件有?80M的exe（实在说，我难以想象怎么会这么大，因此疑问重重的确认了3次，但是他确定的给我说，就是这个大小），并且也谈及了软件存在的主要问题：
?
1.?软件内有几千个Form，都是控件摆上去，然后双击编写代码，连按钮名称和事件名称都不改，都是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?交流。
尽管程度不同，这个公司和我们有某些类似的地方，尤其是代码的历史久远，问题众多，因此方法也值得我们借鉴。