维护一个长期系统的时候，对于程序员的要求就和全新开发不同了。

全新开发项目的程序员的要求就是符合需求、符合技术规范。

而维护一个长期的系统，需求往往是不完整的，很多时候需要从代码中理解程序的结构，据此可以按照程序员重构系统的能力列举出九个层次，正如中国传统文化中经常提到的九重天，正巧有一个“重”字，本文也说说九“重构”天。

一，看不懂代码，按照需求重写

如果需求和程序实现不一致的话，那么就只符合需求了。

这虽然是重构最低的一级，但是放在程序员开发中，也是中上等的程序员了，因为很多程序员按照需求文档都不能正确实现需求。

这也像是仙侠小说中的修炼，只有普通人中的上上天资才能进入修炼天道的门槛。

二，能对照需求理解代码，按照理解后的需求重写

和第一层类似，不过在对照需求理解代码的同时，能挖掘出很多需求文档中没有写，但是代码中已经实现了的需求。

如果类比仙侠小说，这就开始有了一定的领悟能力了。

三，能对照需求梳理代码，按照梳理后的需求重写

理解和梳理不同，理解是看到一块代码理解一块代码，而梳理则是在理解的基础上，还能抽象出已经实现的代码的结构，尽管这种抽象是体现在代码中，但是并没有明确的写出来，而且散乱在很多地方，需要程序员汇集整理。

如果类比仙侠小说，这就是在领悟了个别动作之后，能自己把独立的动作联系在一起了。

前面三个层次，都是重写，也就是需要重新完成原有的工作，需要投入相当一样的工作量。

四，当原有代码有一定质量的时候，能看懂代码结构，可以遵照原有代码结构进行小范围增加

这里面的要求是原有代码有一定质量，如果原有代码质量差，那么还是重写吧。

第四层还有一个意义，也就是这个级别的程序员，工作可以不断的累积，同时不会降低代码质量。

五，当原有代码有一定质量的时候，能看懂代码结构和所涉及的代码，可以遵照原有代码结构进行小范围修改

增加和修改不同，增加是追加逻辑，不影响原有逻辑，而修改可能影响原有逻辑，特别是原有逻辑之间存在隐含的依赖关系的时候。

修改的前提也是原有代码有一定质量，而且代码的修改也是要一直不低于这个级别的程序员，这样工作才能累计，而且不会降低代码质量。

六，当原有代码有一定质量的时候，能看懂代码结构，可以遵照原有代码结构修改代码结构

修改代码结构可能很多人觉得这种情况很少见，事实上最常见的就是升级框架，升级第三方库等各种基础代码。

在实际项目中往往被忽视，甚至有的企业会安排新手做这件事，因为觉得没有实现什么新需求，不创造价值。

对于成熟的框架、第三方库来说，因为已经有大量的升级实践发现了各种缺陷，不过对于不成熟的框架和第三方库来说，特别是企业内部专属的框架和库，升级后不兼容甚至原有逻辑混乱的情况就很常见了。这时候不可能全部项目重写，就需要有这个能力的程序员在升级结构的同时保证程序质量。

和前面两层同样，类似的工作需要有相同能力的程序员才能保证代码质量，有些公司经常是让新手重构，然后搞砸了让熟手打补丁，这种安排和逼人离职差不多。因为代码结构已经混乱了

七，当原有结构清晰健壮的时候，能扩展原有结构

这种情况主要出现在集成的时候，几个程序的结构都清晰健壮，但也需要有人把两者集成在一起，当然，到了这个层次的程序员的重构工作就不再是具体需求了，而是扩展结构后让其他程序员按照扩展后的结构继续开发了。

八，当原有结构清晰健壮的时候，能调整原有结构

这种情况主要出现在基础架构调整，同时不想重写业务代码，就需要在中间的结构层面进行调整，例如单机部署变成集群部署，就需要调整结构，使得调整过程对业务代码透明。当然，这不意味着是最优的，后续还需要对业务代码按照新的结构调优。

九，当原有结构清晰健壮到时候，能重构原有结构

这种

神的世界我是不懂的

但是

不能否认世界上有这种神级程序员