开发中很少有机会能从头开始做一个系统,经历最多的就是在已有系统中添加功能,或修改别人的代码,有人调侃"填别人的坑,同时让别人填自己的坑"。不管是新功能还是改原有逻辑,我们尽量保证从自己手中产出的代码有较好的可维护性。新功能就规范设计和开发,原功能的修改,即使原模块再混乱,也可以在混乱中形成一个可维护的代码区域(气泡),而不是乱上加乱。
设计功能和改动代码时:
- 带着同理心
- 秉持生长性修改原则
- 做到只改一处
- 争取做到只在一处改
生长性修改
对已有代码的修改,每次修改是都一次改进和优化,使其更加易改,而不是盲目的缝补丁。
同理心
多想一想,假如一个月后自己再来看之前写的代码,能不能看懂?
同样的,之后别人接手你的代码,能不能看懂,好不好维护?
- 做到只改一处(合)
即 合并与复用,相同的代码不要重复出现
● 避免重复代码
● 合理的提取、封装类和方法
● 定义常量,避免魔法值
- 做到只在一处改(拆)
即 代码逻辑层次的划分,避免相似代码散落各处
● 遵循单一职责(只做一类或一件事,包、类、方法只有一个引起它变化的原因)
● 逻辑相关的放一起
● 无法显示关联的代码通过注解、@See文档标记进行兜底
● 多个相似、重复度高的代码,重构、重载、或者封装成策略算法族(高内聚)
- 总结和思考
● 编码应该逻辑上高内聚(即单一职责,只做一类[class]或一件事[method])
● 有整体的设计,自顶向下编程(不会造成层次和逻辑混乱)
● 良好的命名和明确的参数说明
● 文档说明或有效注释(在精不在多)
● 做到表面整洁不凌乱,内在简洁不混乱