祖传代码是如何产生的?
程序员在写代码的时候,有时候是秀操作,有时候是不知道怎么写,那就按照直觉去写代码,最后祖传代码大都变成了一坨代码。
祖传代码的特点
- 复杂的多重/虚拟继承
- 文件散布在无数目录中
- 使用来自地狱的动态结构进行查询 - 如运行时拼接各种部分形成的名称的字典等
- 动态加载和其他难以追踪的技术
- 一系列近乎相同的名称,如 DriverController、ControllerManager、DriverManager、ManagerController、controlDriver 等,而且它们还相互调用
- 使用多层装饰器、复杂的类模板、代码生成等技术
- 如果有文档,很多时候文档与代码不配套。或者干脆没有文档
- API混乱,没有层次,随意破坏封装性
- 等等
一言以蔽之,祖传代码远看是一座楼,近看原来一座危楼 :)
面对祖传代码,怎么办?
教科书上一般是这样写的
在编程上
- 团队使用统一的代码风格
- 尽量复用已有的代码,而不要重复造轮子
- 注重代码的可读性,多写注释
- 在可能出现异常的代码段做相关处理
- 编写单元测试
- 等等
在整个软件工程上
- 在编码之前进行充分的需求分析和设计,包括功能定义,算法逻辑,架构设计,接口设计等。分析和设计占80%时间,编码占20%时间,当然80%和20%都是虚值,希望的是设计多一些时间,具体实施就会快一些,而且质量还高
- 在编写代码之前,应该制定完整的测试计划,并执行各种测试,例如单元测试、集成测试和系统测试等
- 代码审查是一种重要的技术,可以帮助你发现代码中的错误和缺陷,并提供建议来改善代码质量。代码审查> - 可以通过组织内部和外部同行评审等方式来实现
- 敏捷开发,小步快跑
- 持续集成和交付
- 等等
但是到最后,虽然懂了很多道理,但是依然过不好这一生。
那么怎么办呢?
- 【统一思想】技术leader要统一大家的思想,上面说的教科书上写的软件工程规范要多多宣讲
- 【自动控制】很多规范性的东西尽量可以自动检查,比如代码规范,在用git提交代码的时候,如果不规范,就无法提交;提交代码后,自动跑流水线,如果不过,无法发起代码merge request
- 【代码评审】这个步骤,我自己认为非常重要。很多公司都有这一步,但是有时候形同虚设。怎么办呢?利益共同体,就是代码评审和代码编写认为是同等贡献。这样作为评审的人员就会有动力去做这件事情,因为绩效考核的时候,可以把这个作为自己的工作量。作为组织,相当于有了备份人员,如果代码作者请假了。评审的人员就可以及时顶上来解决问题。在代码评审的时候,不仅需要检查代码逻辑是否合理,是否有漏洞,还要检查代码风格,比如命名是否合理,注释是否清晰完整,单元测试是否覆盖了所有接口。代码结构是否合理,是否需要局部重构等等
- 【架构反思】不要过度设计,如无必要勿增实体,经常思考整体架构是否合理,检查各个模块的接口是否合理,单元测试是否完整。发现不合理的地方,及时重构,维护项目的接口文档
- 总之,核心的想法是:尽量自动化加人工评审。让自动化过程保证开发过程中固定不变的部分,让人工来保证可变的部分。固定和可变部分的分割也不是一成不变的,我们期望的是自动化过程越多越好。但是有时候,固定部分也需要人工的干预。所以,需要辩证的去看待,动态调整两者之间的界线。
世界终将走向无序,我们能做的就是延缓这个过程。祖传代码无药可救的时候,完全重构将是唯一的选择。