在感觉项目代码的构架不行的时候,你们会怎么办?

十多年的软件研发经历告诉我，所有的项目、系统到后期都会遇到类似的问题，其中人员变动、需求变更是最大的原因。

在日本，很多银行的软件系统还在使用COBOL，美国国防部核弹部队仍在使用软盘，估计很多年轻的程序员连软盘什么样子都不知道。那么他们为什么不推倒重来呢？归结起来其实就是风险和成本的问题。

一个系统在生命周期可能十年或者更多，在此期间，如果没有完整的开发、运维和更新记录，你甚至连一份完整的需求、设计文档都没有，在加上人员变动，有时候系统里面一个看似很tricky的东西修改掉就可以造成系统的重大故障，在这种情况下重新整理需求本身已经不可能，把系统推到重来更简直是自杀。

就风险来讲，本人曾经在金融IT行业做过，参与过银行的核心系统升级和切换工作，开发工作动辄就是上千人的开发团队，涉及厂商上百家，预算以亿计，开发完成后升级切换的过程跟卫星发射有的一比，前期演练N多次，切换现场有指挥中心、科技队伍、厂商保障队伍、后勤队伍，医务保障队伍一应俱全，如果切换失败影响营业，不但可能造成巨大的经济损失，银监、客户也绝对不能饶了你。

就成本来讲，一个系统到了一定年限一般来说有两种可能，第一种是系统已经逐渐不再符合市场需求，起到的作用越来越小，那么，花大成本对系统进行升级改造和替换都不再划算，用最小的代价保证系统可用就行。如果一个系统市场前景越来越大，原有技术架构和设计或者功能设计不满足市场需求，那么就有必要花成本对系统进行升级改造或者干脆推出换代产品进行替换。

回到话题，怎么样才能避免项目/系统后期一团糟的情况呢：

1. 制定系统设计、开发规范和研发流程，并严格遵守，最大限度的避免人员变动造成的系统架构、设计和代码风格的变动。
2. 把系统重构贯彻到每次代码变更的过程中，不符合规范的代码、有问题的代码发现了就修改掉，不在系统的伤口上撒盐。不因为时间紧迫而错上加错。
3. 周期性的进行代码Review和小范围的重构。

在敏捷开发里面常说的一句话是：make it work, make it better, make it perfect。先把系统跑起来实现商业价值，再不间断进行优化，把这三句话贯彻到每一个研发周期中，就能最大可能的延长产品的生命周期。