程序员的九大重构天梯

“java程序员”
开发一个项目系统和后续维护一个系统，这两种需求对于程序员的能力要求是完全不同的。

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

而维护一个长期的系统，内部的代码往往是不完整，纷繁杂乱的，很多时候程序员往往需要从这些代码中理解程序的结构，理解其逻辑关系，然后才可以修改更新。

因此我们可以按照程序员重构代码的能力划分成九个层次。本文就讲讲代码重构九重天。

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

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

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

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

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

这时候有了一定的领悟理解能力了。

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

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

这就是在领悟了各种代码之后，能自己把独立的抽象概念汇聚融合在一起了。

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

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

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

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

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

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

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

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

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

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

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

和前面两层同样，类似的工作需要有相同能力的程序员才能保证代码质量，有些公司经常是让新手重构，然后搞砸了让熟手打补丁。

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

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

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

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

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

这种大神级的世界我是不懂的

但是

不能否认有这种超乎想像的程序员存在。