以下，是我看到的一篇博文：
最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上，任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0，唯一的办法就是花数月时间完全重构这个系统。
对于这事我有两点要说。首先，在我离开这个公司前，这个系统的单元测试覆盖率已经达到了 85%，所以，不要责备我。第二，这么大规模的重构？肯定会出问题。
每一个系统里都至少有一个成为人民公敌、让所有人害怕的组件。它承载了太多的任务，它拥有太多状态，太多的其它组件调用它。当时间到了偿还技术债务的时候，人人都会把目光投向这个组件。然而，如果你对这个组件只有一个不全面的理解，你放下所有工作来完全重构它，那你成功的几率会很小。这个组件，就就它表现出来的令人恐怖的程度和复杂相比，它的实际情况会比你想象更复杂，更恐怖。
你认为这个组件是如何发展成这样一个不幸的状态的？是因为公司雇用了一个笨蛋，让他肆无忌惮的往系统里增加复杂度？或是因为这个组件最初设计的太抽象，由于多年来需求的变更，它的责任范围不断的扩大？(出于个人的自尊，我宁愿相信这个“职业杀手”属于后者)。十有八九，这个组件变成如今这个恐怖的状态，都有由“聪明人”的一些“好意”造成的。如果你决定做一次大的重构，你实际是欠下了另一笔技术债务留给后人。
为了能真正的彻底偿还这笔债务，你需要去分解这个系统的复杂度。你需要花时间寻找所有调用这个组件的客户端。你需要花时间跟你的同事交流，了解这个这个组件的历史和它是如何被使用的。你需要简化这个组件的周边环境，看看它是如何运作的。每周，你都需要花更多的时间来更清楚的了解这个组件的业务。只要有足够长的时间跨度，你最终能理清所有复杂的问题。
从实际方法上说，这个问题应该怎么办？与其现在花 3 个整月的时间做一次完全的重构，不如先用一个季度的时间做清理工作。最后还是要重写，但有了 3 个月的计划准备，你有了时间去分析和设计。你有了时间来理清业务。
真的很有感触，我所在的上个公司似乎也有一个这样的项目“XXX数据采集”，项目很小，但是丝毫不影响让看到它的人抓狂。最开始全面负责维护的“石同学”，抱怨项目太烂，辛苦维护了一阵，走了。接下来来了个新人“张同学”，全面负责维护，干了四个月，怒气冲冲的走了。“包同学”接下了任务，抱怨了两周，恨不得把我们都喊过去看看那种让人发指的代码。我们也很无语。
上个公司的主要项目，“XXX执法系统”，是我们几个一点一点搭建起来的，花了半年时间，开发出来一个比较全面的版本，鉴于水平有限，仍有许多局限，但是，它的稳定性还比较让人满意。接下来，在领导的指挥下，我们把项目重构、拆分，增加注释。一方面偿还曾经的技术债务，一方面又欠下了新的债务，似乎欠的更多了。一个主要项目，拆分成了五个支持项目，加一堆jar包，甚至出现一个同事长达两周的时间运行不起来的情况。我们一方面能生成很详细的项目API，让看到他的新人都能很快浏览整个项目，另一方面，我们项目的主要开发人员都不确定能否很快的把项目搭建起来了，包括重构而带来的隐藏的未知数量的Bug。
我们不知道，我们偿还的债务多还是新欠下的债务更多。
我很不负责任的，在第一轮测试周期完成后，离开了那家公司。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
