高质量代码的三大要素：

可读性、可维护性和可变更性

做好代码规范、提高代码质量，能显著增强代码的可读性、可维护性和可变更性。努力提高代码的读写可维护性，是做好代码规范的必要非充分条件。代码规范和架构设计是软件的灵魂所在，代码质量偏低，就像是人失去了三魂七魄中的一魄，就会丧失活力，影响正常运行，增加软件交付后维护成本，出现推迟完成、超出预算、特性缺失等现象。

任何语言都需要强调编码风格的一致性。只要是团队开发，每个人都以相同的方式编写代码就是至关重要的。这样大家才能方便地互相看懂和维护对方的代码。

实际上，每家公司都会有一份（或多份）代码规范，因此提高代码的读写可维护性的关键在于是否能落实公司的相关文档，公司的技术总监、项目经理或相关代码审查机关是否具有应有的执行力。如果不能落实，那么即便代码规范画得再美，具体的代码也会丑到崩溃。

代码规范

如果不想为以后挖坑，做好代码规范是程序员和团队负责人、项目经理的必修课。如何保证当前项目开发过程中压力正常，而不是在后期面对过多的压力、以至于噩梦缠身？最简单的办法就是照看好你的代码，也就是落实好公司的代码规范工作。每天为此付出一丁点的努力，便可以避免代码腐烂，并保证代码产品日后不至于变得难以理解（可读性）和维护（可维护性）。

代码的可读性

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

• 编码风格一致
• 代码清晰表达意图
  • 写别人看得懂的单词，如果选用英语，那么避免日语、法语和汉语拼音等，尽量使用语义化的命名组合；
  • PIE 原则：意图清楚而且表达明确地编程；
  • 能够让人快速看懂（最低限度的要求是自己一个月后能快速读懂）；
• 恰到好处的注释
  • 不能太多或太少，注释的形式根据代码具体的情况有不同；
  • 避免用注释包裹代码；
  • 尽量留下简明扼要的注释；
• 评估取舍（不要编写大段的代码）
  • 避免写一些现在不需要、将来也不太可能需要的功能：
    • 不完美主义：不多写代码（如会话存储拆分）；
  • 避免做没有太大价值的优化工作；
  • 区分任务的轻重缓急：
    • 头疼医头也医脚：先容忍失败，再解决问题（如节点关闭逻辑）；
    • 不头疼不医头：量化分析（如参数调整回滚等）；
  • 综合考虑一下性能、便利性、生产力、成本和上市时间……
• 简单就是美，避免简单的功能写出复杂的代码；
  • 保持简单的代码远比写出复杂代码要难得多，但这是值得的；
  • 不编写讨巧的代码；
  • 避免无谓的条件嵌套和过度封装；
  • 第一眼看上去就能知道其用处的代码，才是简单而美的代码
  • 坚持操作方法的原子性，而后使用组合模式实现业务逻辑；
  • 避免大段代码，要写高内聚、低耦合的代码；

代码的可维护性

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

编写时可维护性

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

运行时可维护性

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

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

不要把代码写死；

预测可能发生的变化

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

代码的可写性

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

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