代码的可维护性是由很多因素协同作用的结果 . 代码的可读性好、简洁、可扩展性好 , 就会使得代码易维护 ;

相反就会使得代码不易维护 . 更细化地讲 , 如果代码分层清晰 , 模块化好 , 高内聚低耦合 , 遵从基于接口而非实现编程的设计原则等等 .

代码的可读性应该是评价代码质量最重要的指标之一 , 需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等 . Code Review是一个很好的测验代码可读性的手段 .

它表示我们的代码应对未来需求变化的能力 . 在不修改或少量修改原有代码的情况下 , 通过扩展的方式添加新的功能代码 .

• 当添加一个新的功能代码的时候 , 原有的代码已经预留好了扩展点 , 不需要修改原有的代码 , 只要在扩展点上添加新的代码即可 .
• 当要实现一个功能的时候 , 发现原有代码中 , 已经抽象出了很多底层可以复用的模块、类等代码，可以拿来直接使用 .
• 当使用某组接口的时候 , 如果这组接口可以应对各种使用场景 , 满足各种不同的需求 .

尽量保持代码简单 . 代码简单、逻辑清晰 , 也就意味着易读、易维护 . 例如著名的KISS原则 , Keep It Simple , Stupid .

代码的可复用性可以简单地理解为 , 尽量减少重复代码的编写 , 复用已有的代码 . 可复用性也是一个非常重要的代码评价标准 , 是很多设计原则、**、模式等所要达到的最终效果 . 跟 DRY(Don’t Repeat Yourself)设计原则的关系挺紧密 .

代码可测试性的好坏 , 能从侧面上非常准确地反应代码质量的好坏 . 代码的可测试性差 , 比较难写单元测试 , 那基本上就能说明代码设计得有问题 .

• 面向对象编程因为其具有丰富的特性(封装、抽象、继承、多态) , 可以实现很多复杂的设计思路 , 是很多设计原则、设计模式等编码实现的基础 .
• 设计原则是指导我们代码设计的一些经验总结 , 对于某些场景下 , 是否应该应用某种设计模式 , 具有指导意义 . 比如 , “开闭原则”是很多设计模式(策略、模板等)的指导原则 .
• 设计模式是针对软件开发中经常遇到的一些设计问题 , 总结出来的一套解决方案或者设计思路 . 应用设计模式的主要目的是提高代码的可扩展性 . 从抽象程度上来讲 , 设计原则比设计模式更抽象 . 设计模式更加具体、更加可执行 .
• 编程规范主要解决的是代码的可读性问题 . 编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节、更加能落地 . 持续的小重构依赖的理论基础主要就是编程规范 .
• 重构作为保持代码质量不下降的有效手段 , 利用的就是面向对象、设计原则、设计模式、编码规范这些理论 .