一个在运行的活的大系统是一个怪兽，需要大量年富力强的程序员的献祭

一个在运行的活的大系统是一个怪兽，需要大量年富力强的程序员的献祭（误）
----大魔法师：Prog Rammer

这个怪兽是怎么长成的？

这里有一个 核心系统，包括一些基本的逻辑，和最初的数据库表。系统上线了赚钱了开发团队散了。第二批维护的程序员不敢/没时间去迭代整个基础架构，只能根据业务需求往系统里加逻辑。 腐败首先发生在数据库结构上，因为以前的结构不能动，所以新的业务采用了各种关联表和老数据整合，结果是关联表和相关VIEW、SP都进入神圣领域，变成不可更易的一部分。

随着业务扩大和行业竞争，需要更多的团队一起来折腾这个系统，在匆忙的抢市场大战中，没有代码Review，甚至没有开发规范，程序员的唯一指标是 快快快，结果就是你看到的工具的滥用。但没人愿意去修改别人的代码，自己的代码都还没搞完呢。年复一年，大家甚至都不想打开盖子看看这里面是怎么运作的，这个系统能安全运行完全依赖QA的那几个老人，他们知道每个变更来的时间，也有完整的回归测试用例（也许没写下来，但在脑子里）

大魔法师：Prog Rammer

这时候业务还在扩张，这个怪兽的胃口更大了。只能招进更多的程序员，严格控制上线流程，每次迭代一小部分，在系统上增加各种各样，毫不相干的外挂。核心系统现在成为一个数据来源，外围业务需要数据时，通过一条长长的流程去取，涉及到安全性的问题，还得做跨网段跨数据库访问。

题主刚进公司，作为将被献祭的牺牲，要让他先膜拜一下伟大的怪兽，所以题主暂时没有明确的工作任务，而是得到了一个每个新人都会被问到的问题：

“来读读svn的代码，看看系统有没有办法改进？”

TL以为给了题主三支香，让题主去拜拜怪兽之后回来好好牺牲。而题主觉得自己获得了一把龙枪，随时可以去肢解怪兽。。。

--------------------------------------现实世界分割线-----------------------------------------

这类系统的重构不应该由技术部门发起，因为 这不是代码级别重构可以解决的问题。
当然可以整合Log之类的工具类，但这没有意义。

唯一的出路是 重做。

根据业务增长变化，对 业务进行一次完整的梳理，引用新的观念，将业务重新分析封装。在此基础上设计 全新的数据库结构和底层架构。
规范设计流程，在底层上 逐层进行设计，每一层的边界都做好确认，层与层之间用API或协议连接。
之后是翻译代码，在实现层上逐笔重现业务。
预留充足的工期和团队，由 企业最高领导发起。

--------------------------------------为什么花钱分割线-----------------------------------------

题主所在的公司是行业老二，所以 压力和动力都很大。
每周四次发布， 行业变化非常快。
代码库能开放给新来的题主，公司的工程师氛围是不错的， 代码规模也不太大。

一个新兴行业的第二名，应该有足够动力去改进基础设施，改进的好，可以用10年。开发成本大概是你们现在程序员的数量*1.5+程序员一半数量的QA，工期9个月到一年。

改进的最大阻力在于项目在挣钱，领导层没动力改；其次是招不到这么多合适的人