面对祖传代码怎么办

祖传代码是如何产生的？

程序员在写代码的时候，有时候是秀操作，有时候是不知道怎么写，那就按照直觉去写代码，最后祖传代码大都变成了一坨代码。

祖传代码的特点

• 复杂的多重/虚拟继承
• 文件散布在无数目录中
• 使用来自地狱的动态结构进行查询 - 如运行时拼接各种部分形成的名称的字典等
• 动态加载和其他难以追踪的技术
• 一系列近乎相同的名称，如 DriverController、ControllerManager、DriverManager、ManagerController、controlDriver 等，而且它们还相互调用
• 使用多层装饰器、复杂的类模板、代码生成等技术
• 如果有文档，很多时候文档与代码不配套。或者干脆没有文档
• API混乱，没有层次，随意破坏封装性
• 等等

一言以蔽之，祖传代码远看是一座楼，近看原来一座危楼 ：）

面对祖传代码，怎么办？

教科书上一般是这样写的

在编程上

• 团队使用统一的代码风格
• 尽量复用已有的代码，而不要重复造轮子
• 注重代码的可读性，多写注释
• 在可能出现异常的代码段做相关处理
• 编写单元测试
• 等等

在整个软件工程上

• 在编码之前进行充分的需求分析和设计，包括功能定义，算法逻辑，架构设计，接口设计等。分析和设计占80%时间，编码占20%时间，当然80%和20%都是虚值，希望的是设计多一些时间，具体实施就会快一些，而且质量还高
• 在编写代码之前，应该制定完整的测试计划，并执行各种测试，例如单元测试、集成测试和系统测试等
• 代码审查是一种重要的技术，可以帮助你发现代码中的错误和缺陷，并提供建议来改善代码质量。代码审查> - 可以通过组织内部和外部同行评审等方式来实现
• 敏捷开发，小步快跑
• 持续集成和交付
• 等等

但是到最后，虽然懂了很多道理，但是依然过不好这一生。

那么怎么办呢？

• 【统一思想】技术leader要统一大家的思想，上面说的教科书上写的软件工程规范要多多宣讲
• 【自动控制】很多规范性的东西尽量可以自动检查，比如代码规范，在用git提交代码的时候，如果不规范，就无法提交；提交代码后，自动跑流水线，如果不过，无法发起代码merge request
• 【代码评审】这个步骤，我自己认为非常重要。很多公司都有这一步，但是有时候形同虚设。怎么办呢？利益共同体，就是代码评审和代码编写认为是同等贡献。这样作为评审的人员就会有动力去做这件事情，因为绩效考核的时候，可以把这个作为自己的工作量。作为组织，相当于有了备份人员，如果代码作者请假了。评审的人员就可以及时顶上来解决问题。在代码评审的时候，不仅需要检查代码逻辑是否合理，是否有漏洞，还要检查代码风格，比如命名是否合理，注释是否清晰完整，单元测试是否覆盖了所有接口。代码结构是否合理，是否需要局部重构等等
• 【架构反思】不要过度设计，如无必要勿增实体，经常思考整体架构是否合理，检查各个模块的接口是否合理，单元测试是否完整。发现不合理的地方，及时重构，维护项目的接口文档
• 总之，核心的想法是：尽量自动化加人工评审。让自动化过程保证开发过程中固定不变的部分，让人工来保证可变的部分。固定和可变部分的分割也不是一成不变的，我们期望的是自动化过程越多越好。但是有时候，固定部分也需要人工的干预。所以，需要辩证的去看待，动态调整两者之间的界线。

世界终将走向无序，我们能做的就是延缓这个过程。祖传代码无药可救的时候，完全重构将是唯一的选择。