如何编写可信赖的代码

软件， 逻辑之塔， 精微的艺术。

遵循严格的代码规范， 学习好的编程模式， 避免常见的编程错误， 持续小步重构改进， 严格测试与必要文档， 理解所写的每一行代码， 正确使用
API， 代码 Review ， 追求更好的解决方案， 注重整体设计

作为一名合格的程序员， 需要满足的两个最基本要求：

1. 能够编写值得信赖的程序和文档；

2. 能够无障碍地与团队成员进行探讨交流。

假设我们是一段代码的使用者， 对代码的要求会是怎样的？

代码有必要的文档， 详细说明了它的主要意图及设计思想；

代码出色地完成了它所声称的工作， 对于不合法情况能够给出合理的返回结果或友好提示； 能够应对大数据量；

代码稳固， 在异常情况下依然坚挺， 至少可以给出友好提示， 或降级运行；

容易读懂、修改和扩展。

通常情况下， 主要考虑以下质量属性： 正确性、性能、 健壮性、 可维护性。

什么样的代码是不可信赖的？

1. 没有文档；

2. 不能（正确有效地）完成代码文档所声称的事情；

3. 不能处理不合法情况；

4. 无法应对大数据量的情况；

5. 没有错误提示或不友好；

6. 可能被恶意代码攻击；

7. 难以读懂、理解和修改；

这就有几个问题要思考一下， 可以根据这几个问题按图索骥， 一步步地逼近高质量编程。

1. 这段​代码想要完成什么样的工作？ 要求怎样的输入， 可以预期获得怎样的输出（输入-输出模型）？

2. 什么是合法情况， 什么是不合法情况？ 如何统一处理， 减少这种合法性检测的时间成本？

3. 代码所要应对的数据量有多大？ 是否可能存在时间或空间上的性能瓶颈？ 如果有， 需要仔细设计好的结构和算法去解决；

4. 代码所运行其中的环境如何（数据库操作/网络调用/文件读写）？ 可能发生怎样的异常，导致什么错误？ 如何进行异常处理？

5. 如何保证代码可读？ 是否有可扩展性需求？ 如果有， 需要在哪些方面提供灵活性？

基本方法：

1. 编写文档， 描述所要完成的工作， 输入是什么， 输出是什么； 这是一个自我表达的过程， 有助于清晰思路；

2. 编写有效的测试用例， 设立检验关卡。

3. 编写代码， 持续小步重构、改进， 必要的时候同步更新文档， 通过测试用例；

4. 代码Review. 添加新的测试用例或需求， 持续改善。

以上采用的是“文档与测试导引” 的方法。既要写文档， 又要写测试， 这种方法看上去工作量大， 实际上反而可能是一种捷径。 实际上， 文档、测试、开发三者的本质都是表达， 彼此会是相辅相成的。 当然， 与“测试驱动论”或“文档驱动论”不同， 编写文档以及通过测试用例并不是最终目的， 只是一种检验途径。 还需要尽力去编写可读性良好的代码。

编写可信赖的代码， 需要采用多种方法和手段去逐步逼近。 以下是一些好的做法：

1. 确定一种严格的代码风格和规范， 严格遵行它。 良好的代码风格不会保证程序的正确性， 但是能保证代码清爽易读，更容易找出错误；

a. K&R C 代码风格， 详见 《The C Programming Language》 ；
b. 《Java 编程规范》；
c. 统一命名， 必要的注释和文档 ；

2. 阅读 《 Effective Java 》, 《代码整洁之道》， 《Writing solid code》、 《编写可读代码的艺术》《代码大全》, 《Unix / Linux 设计思想》，《敏捷技能修炼》， 《程序设计实践》（K&R） 等编程书籍， 掌握好的编程理念和模式， 尽可能使用习惯用法和推荐用法，这些有助于避开一些常见陷阱，
自然地写出好的代码；

a. 集合/容器遍历： 使用 foreach 或 迭代器模式；
​ b. 数组遍历采用半开半闭模式： begin <= index < end ；

b. 自顶向下， 意图导航；
c. 搭建原型， 逐步细化；
d. 接口与实现分离解耦；
e. 构造与使用分离解耦；
f. 事件与处理器链分离解耦；
g. “一个事实”原则； “对修改关闭， 对扩展开放”原则； KISS 原则；

h. 充分利用已有成熟库和组件；
i. 通过封装， 屏蔽低层复杂性， 使用容易理解的高层语义构建程序；
j. First Make it Right, Then Make it Good.

3. 熟悉常见错误代码模式， 避免犯相同的错误。 聪明的人从别人的错误中汲取教训。 《Code Quality: The Open Source Perspective》 这本书从代码层面深入讨论了各种编程错误。

a. 变量未声明或初始化即使用； 作用域过大； 无意识的名字冲突；

b. 运算符误写； 优先级错误； 计算溢出； 不正确或不成熟的算法；
c . 越界错误； +1 或 -1 循环错误； 空处理错误； 临界处理错误；

d. 不正确或不完整的 API 调用； 对返回结果不作检测；

e. 缺失错误处理或草率了事， 比如捕获异常却不处理；
f. 同步更新错误， 比如添加的新字段没有被输出， 关联字段未能同步更新；

g. 并发与时序错误， 比如 并发修改共享可变对象容易产生并发错误， ajax 异步调用容易导致时序错误；
h. 资源泄露， 比如打开文件却没有关闭；
i. 缓冲区溢出； 恶意代码注入；
j. 权限赋予不当； 应用目录泄露；
k. 使用复杂算法过早优化；
L. 手工解析输入而不是使用成熟的库； 未作参数合法性验证；
m. 残留的无用代码；
n. 代码与文档不同步；
o. 错误的类型转换， 或其他转换；
p. 未能正确理解需求；
q. 使用全局变量而无意识地修改；
r. 使用冷僻用法或奇淫巧技；
（探索精神是可嘉奖的，但不宜用在项目中）

根据二八定律， 80% 的 BUG 是由 20% 的编程错误引起的， 因此， 熟悉这 20% 的编程错误并避免之， 就能避免 80% 的BUG 。此外， 有些 BUG 可能是由系统集成导致的， 属于更精微的层面， 另当别论。

充分利用编译器及静态代码分析工具检测代码。

4. 持续小步重构改进，消除重复和代码坏味；

a. 重复代码抽取为公共方法；

b. 相似逻辑提炼框架处理；

c. 使用设计模式优化结构；
d. 充分使用短小函数；

e. 删除未用到的代码；

5. 设立严格的检验关卡， 仔细测试；

a. 优先级： 关键部件 》 常用部件 》 不常用部件；

b. 正常情况测试；

c. 临界情况测试: 空/越界/一/二/；

d. 等价类测试；

e. 分支测试；

f. 性能压力测试；

6. 深入理解实现原理和细节，准确理解和使用 API， 理解代码所做的事情；

a. 完整理解 API 含义， 而不是一知半解的情况下调用；
b. 检测 API 返回值并作出合理的措施；
​ c. 理解自己所编写的每一行代码， 它是如何与框架进行交互的；

​

​ eg. jquery $.ajax() 方法， 充分理解该方法所涉及的概念和知识点

​ String vmName = request.getParameter(HouyiApiParams.KEY_VM_NAME);

​ 容器框架是如何获取到该参数的值的。

7. 代码讲解，有助于发现所犯的错误， 也能锻炼口头表达能力；

a. 团队成员之间进行代码 Review；
b. 给自己讲解所编写的代码；

8. 思考更好的表达方式和方案， 追求更好的可维护性；

a. 使用多线程并发处理 IO 调用， 而不是迭代；
b. 使用异步调用改善响应流畅性；
c. 使用 API 接口代替数据库查询；
d. 对于简单方案的性能较低的实现方式， 思考更有效率的实现方式；
e. 对于代码中不太清晰的地方， 逐步替换为更清晰的实现；

9. 阅读优秀开源项目代码， 潜移默化地汲取优秀的做法、思路和方案；

10. 关注整体设计、细致编程、考虑周全； 有些问题是由整体设计引入的， 比如整体的错误处理， 无法通过局部层面来解决。

不当的架构设计会使代码修改和扩展变得困难， 迫使开发者编写大量临时方案去解决某个具体问题； 日积月累， 整个系统就会越来越腐烂， 越来越难以维护。 始终保持简洁有效的架构设计。

形成开发与测试的良性循环，建立高质量编程的一套方法和习惯（包括开发时间估算）， 对每一个功能都能遵照这种方法和习惯。

时间与质量的平衡。