《清单革命》对程序开发的一些启示

  周末重温了一遍阿图·葛文德的《清单革命》，其副标题“如何持续、正确、安全地把事情做好”是各行各业都想实现的梦想。而对应到具体行业时，各类从业者的“清单革命”又各有不同。书中大部分描写的是医疗、建筑、餐饮、零售等传统行业上的例子。通过清单的规范，能有效地降低从业者失误从而提高效率。

  对于程序开发，经历了从《人月神话》中「没有银弹」的尴尬境地，到如今行业渐入正轨：流程规范化、功能模块化、参数配置化。程序开发的过程中各道“工序”也日渐明确。以下是《清单革命》给我带来的一些启示。

  

“无知之错”与“无能之错”

  

无知之错：犯错是因为没有掌握相关知识，可以被原谅

  无知之错，在程序开发早期有很多案例，如著名的“千年虫”，第一个蠕虫病毒、Intel奔腾浮点指数除法等等。在这些都是在探寻未知里程时开拓者们遇到的坑。如今大数据时代或许还会出现前所未闻的BUG，但相比前人这种几率势必小得多。

  

无能之错：犯错是因为未能正确使用知识，不能被原谅

  程序开发中的“无能之错”为QA部门提供了主要的工作内容。

  无论是小到文案拼写错误，还是大到死循环宕机，这些BUG都是像抗日神剧中翻来覆去出现的场景。

  或许是赶工期无法面面俱到，但一些常识和关键点对于程序开发来说也是必须要卡好的，如字段长度确认、日期格式转换、接口字段对齐、SQL索引命中、逻辑判断分路完备、页面正常渲染、避免死循环等等。不同程序员或许侧重点不同，前端同学侧重于UI交互，后端同学侧重于接口事务。

但和医疗行业相似的是，程序开发也是一个“我们所掌握的知识数量和复杂程度，已经超出了个人正确、安全和稳定地发挥出其功效的能力范围“的行业。

  

开发关键点比“大而全”更重要

  “在重压之下，人们特别容易忽视一些单调的例行事项” 和 “人们会麻痹大意，会故意跳过一些明明记得的步骤”。

  这两句或许就是程序员日常犯错的缩影。书中的例子是将通过将消毒皂的使用写入清单，大大降低感染率。显然彻底地做好消毒工作在此之前没有被重视，也是医护人员容易忽略的环节。

  对照程序员呢？或许正确理解用户需求也是极易被忽略的环节。没有理解好用户需求的细节直接开工的情况比比皆是。测试或上线后才反馈出来。当然这块也因人而异，每个人在回顾自己的BUG列表时都能大致发现自己开发过程中容易忽略的关键点。

  个人总结的一些关键点：

• 明确需求，文档落实
• 接口对接，细化到字段格式
• 关键业务节点打印关键日志，做好异常捕获
• 提测之前先打包，开发环境部署验证
• 待补充…

  

团队开发与清单

  

代码审查

  程序开发早已过了金山软件求伯君当年那种孤胆英雄的时代。绝大多数程序员不是独行侠，通常都是团队。团队中的代码Review能大大避免错误的发生。这点相比其他行业算是一大优势吧。提倡团队代码审查，加上Sonar代码扫描，保障团队代码质量。团队代码审查也能出个清单：

• 接口方法/变量命名是否规范；
• 代码复用率/公共方法抽取；
• 是否符合开闭原则；
• 异常捕获处理；
• 注释数量及规范；
• 待补充…

方案决策

  书中建筑团队在进行方案决策时会找来很多行业专家开会决定。“无论在设计时有多么困难，都没有犯错的余地。因为错误意味着送命和巨大的经济损失”。开发团队在遇到方案决策时，需要每个人用自己的专业知识来评估方案。也就是用每个人认知中的知识清单来判断方案的优劣，用团队的认知网络来避免个体的认知偏差。程序开发方案也需要由系统架构、安全审计、网络部署、产品开发、QA测试等部门敲定。

  

权力下放

  书中的例子是沃尔玛在“卡特里娜”飓风中救灾的例子。不是简单地分权就行，更关键地是让每个人都能担负起自己的责任。程序开发过程也是一样，个体要向团队负责，可以通过清单来确保充分沟通、互相协调、承担责任、明确自己的权力和责任。

  我也列了个清单：

• 定时反馈负责模块开发进度；
• 遇到阻断性问题时逐层汇报；
• 主动进行业务系统间联调测试；
• 及时响应和处理反馈问题；
• 待补充…

  

总结

  综上，《清单革命》或许不能解决“没有银弹”的难题，但至少能让程序开发过程中程序化、规范化不至于“腹背受敌”。文中所列举的清单纯粹是根据个人开发经验推导所得，参考意义不大。每个人、每个团队根据自身情况归纳出自己的清单，才能更好地完成“清单革命”。

作者：麦海杰