工作日常--编写可维护代码

开发中很少有机会能从头开始做一个系统,经历最多的就是在已有系统中添加功能,或修改别人的代码,有人调侃"填别人的坑,同时让别人填自己的坑"。不管是新功能还是改原有逻辑，我们尽量保证从自己手中产出的代码有较好的可维护性。新功能就规范设计和开发，原功能的修改，即使原模块再混乱，也可以在混乱中形成一个可维护的代码区域（气泡），而不是乱上加乱。
设计功能和改动代码时：

• 带着同理心
• 秉持生长性修改原则
• 做到只改一处
• 争取做到只在一处改

生长性修改

对已有代码的修改，每次修改是都一次改进和优化，使其更加易改，而不是盲目的缝补丁。

同理心

多想一想，假如一个月后自己再来看之前写的代码，能不能看懂？
同样的，之后别人接手你的代码，能不能看懂，好不好维护？

1. 做到只改一处(合)

即 合并与复用，相同的代码不要重复出现
● 避免重复代码
● 合理的提取、封装类和方法
● 定义常量，避免魔法值

2. 做到只在一处改(拆)

即 代码逻辑层次的划分，避免相似代码散落各处
● 遵循单一职责（只做一类或一件事，包、类、方法只有一个引起它变化的原因）
● 逻辑相关的放一起
● 无法显示关联的代码通过注解、@See文档标记进行兜底
● 多个相似、重复度高的代码，重构、重载、或者封装成策略算法族（高内聚）

3. 总结和思考

● 编码应该逻辑上高内聚（即单一职责，只做一类[class]或一件事[method]）
● 有整体的设计，自顶向下编程(不会造成层次和逻辑混乱)
● 良好的命名和明确的参数说明
● 文档说明或有效注释（在精不在多）
● 做到表面整洁不凌乱，内在简洁不混乱