高质量代码的三个要素：可读性、可维护性和可变性

做好代码规范，提高代码质量，可以显著增强代码的可读性、可维护性和可变性。提高代码的可维护性是必要的，也是不够的。代码规范和架构设计是软件的灵魂，代码质量低，就像人失去了三魂七魄中的一个，就会失去生命力，影响正常运行，增加软件交付后的维护成本，有延迟完成、超预算、失去功能的情况。

任何语言都需要强调编码风格的一致性。只要是团队开发，大家用同样的方式写代码就很重要。这样大家就可以轻松理解和维护彼此的代码。

事实上，每个公司都会有一个(或多个)代码规范，所以提高代码读写可维护性的关键在于公司的相关文件是否能够执行，公司的技术总监、项目经理或相关的代码审查机关是否拥有应有的执行权力。如果不能实现，即使代码规范画得再漂亮，具体代码也会难看到崩溃。

代码规范

如果你不想为未来挖坑，代码规范是程序员、团队领导和项目经理的必修课。如何保证目前项目开发过程中的压力是正常的，而不是后期面临太大的压力导致噩梦？最简单的方法就是好好保管你的代码，也就是实现公司的代码规范。每天付出一点点努力，就可以避免代码衰减，保证代码产品在未来不会变得难以理解(可读性)、维护(可维护性)。

代码的可读性

代码的可读性是指代码让人容易阅读、跟踪和理解的程度。提高代码的可读性可以为代码阅读者节约时间（避免阅读时浪费过多无谓的时间）和精力（Debug、扩展功能或是性能优化的前提条件是你要读懂这段代码）。以下是摘选的可供参考的策略：

编码风格一致

代码清晰表达意图

写别人看得懂的单词，如果选用英语，那么避免日语、法语和汉语拼音等，尽量使用语义化的命名组合；

PIE 原则：意图清楚而且表达明确地编程；

能够让人快速看懂（最低限度的要求是自己一个月后能快速读懂）；

恰到好处的注释

不能太多或太少，注释的形式根据代码具体的情况有不同；

避免用注释包裹代码；

尽量留下简明扼要的注释；

评估取舍（不要编写大段的代码）

避免写一些现在不需要、将来也不太可能需要的功能：

不完美主义：不多写代码（如会话存储拆分）；

避免做没有太大价值的优化工作；

区分任务的轻重缓急：

头疼医头也医脚：先容忍失败，再解决问题（如节点关闭逻辑）；

不头疼不医头：量化分析（如参数调整回滚等）；

综合考虑一下性能、便利性、生产力、成本和上市时间……

简单就是美，避免简单的功能写出复杂的代码；

保持简单的代码远比写出复杂代码要难得多，但这是值得的；

不编写讨巧的代码；

避免无谓的条件嵌套和过度封装；

第一眼看上去就能知道其用处的代码，才是简单而美的代码

坚持操作方法的原子性，而后使用组合模式实现业务逻辑；

避免大段代码，要写高内聚、低耦合的代码；

代码的可维护性

软件可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。笔者这里将其分为两大类：编写时可维护性和运行时可维护性。

编写时可维护性

编写时可维护性是指在程序或系统上线后爆出 BUG，开发团队能够及时扑灭这个 BUG 且不会爆出其他 BUG。保持方法的原子性，提高代码内聚，能使某处修改的影响降到最低，这样某处方法出现 BUG，也不太会影响到其他模块的正常运作。编写时可维护性还包括了代码的可测试性。

运行时可维护性

运行时的可维护性是指在系统运行过程中（或无需再次编码发布、只需系统重启一次）修改系统的某项配置并使其生效，且不影响现在正在进行的业务和用户的操作。这要求软件工程师不能把代码写死。例如配置文件、数据库连接字符串、资源文件、日志等。

以下是摘选的可供参考的策略：

不要把代码写死；

预测可能发生的变化

通过提高代码的复用性提高代码的可维护性

代码的可写性

代码的可写性包括代码的可变更性，代码的可变更性是软件理论的核心。

代码的可写性是建立在代码的可维护性上的，而代码的可写性与可维护性又都建立在代码的可读性上。如果代码难以阅读，那么 BUG 的修正将变得难以入手，新功能的添加就更是无从入手了。