防止工程结构失效

最近在infoQ上看到一篇文章，作者讲述了在项目的持续开发中原来的技术架构会逐渐“腐化”，那些帮助工程师减少工作量的框架和技术也不在复有当初的威力，最初给项目带来的种种好处一点一点丧失。

这是一个不可回避的事实，其原因不仅仅在于代码在系统演进中变得越来越庞大，越来越难以把握，同时随着时间的流逝开发人员的对系统的兴趣和对代码的把握也会呈线性地降低。

事情是一点点变坏的。

为了快捷我们把各个功能放在了一个工程里。好吧，对其他数据结构的引用确实方便了，在笑声还没有停止时，我们发现打开开发IDE building workspace的时间越来越长，寻找相关代码文件的时间越来越长，in one word 和我当前工作无相关的代码越来越多。对于每日构建的C/C++项目来说，花在编译上的时间越来越多，让我越来越想放弃每日构建。

好吧，为了加快项目的进度，为了让我从这无聊的coding中解放出来，我招聘了几个新手。我有信心他们能够做好，因为framework能够帮助程序员把精力集中在，嗯我比较迷信。一开始他们做的很好，但是他们写了更多的函数，这些函数极不规律，有的绕开了framework自己实现，有的调用了系统API，有的重写了framework的函数。程序代码的正交性彻底丧失，各个功能甚至不顾初始化顺序的循环依赖，系统的解决思路变得杂乱无序。

铁打的营盘流水的兵，又有新人进来了。我招聘了一个我认为的老鸟，但是按照我的讲解他已经无法把握现在项目代码了，于是向我索要设计文档。我尴尬地把一些零星不规范的文档给他阅读。可惜这仍然不能让他从代码泥潭中挣脱。

这是个彪悍的程序员，强烈的向我控诉之前程序员的低能，要求重构整个项目。由于我对之前程序员的成见，我同意了。我对未来充满了希望。等我再次拿到代码时，现在设计思路和之前的全然不同，代码也是翻天覆地的重写。之前的一切技术积累都没有了价值，更糟糕的是重构停滞了相当的时间，我不得不包测试外包出去，全部测试一遍，保证工期和质量。这是一笔计划外的支出。我还观察到了公司正在形成一种不正确的价值观，对之前无法把握的代码一种简单有效方式就是推倒重写。我开始咒骂自己当初的决定。

我要改善这一切。

我从新招聘了几个程序员，不管是老手还是菜鸟，我加强了岗前培训。强调了整个项目的设计思路，不允许自行在服务层和引擎级别添加新的函数，不允许重写框架API。努力使程序员的精力集中在业务上，同时也保持公用API的统一和简洁。

建立了项目wiki，帮助开发人员认识理解项目。收集各种问题和解决方案，为公司积累技术财富。

加强开发人员的代码互查，不断地进行微重构，杜绝颠覆的重构，保证公司持续性的技术积累。

将硕大无比原始代码工程重新组织成多个，安正交性分解，降低阅读噪音，降低依赖，架构构建速度。

So far so good，到目前为止看上去还不错