开发Debug检查清单
人的大脑结构决定了我们的思考方式：脑补没有检查的细节，直觉来办事，但事实并非如此——经验再丰富，总会有遗漏——是所谓“常在河边走哪有不湿鞋”，也所谓“智者千虑必有一失”。
无知之错于当前我们无能为力，而无能之错也越来越难以避免——知识的结构越来越复杂，业务的工作越来越急迫&细致要求，复杂性与日俱增。
软件工程是人类迄今为止难度最大的一项团队工作，Debug占用了我们大量的时间，有必要将常见Debug行为清单化。
我们所掌握的知识的数量和复杂程度已经超过了个人正确、安全和稳定地发挥其功效的能力范围。知识的确拯救了我们，但也让我们不堪重负。
在现代社会，面对越来越复杂的工作，人们时常会因为疏忽而犯错，而有效解决这类问题的好方法就是建立一份工作内容检查清单。 ——《清单革命》
参考医学界的《手术安全核对表》，建立《开发Debug检查清单》如下：
- 检查环境配置
- 检查包版本
- 检查URL
- 无法访问时，是否连接代理了？
清单在手，淡定从容。“花繁柳密处能拨开方见手段，风狂雨骤时可立定才是脚跟”。
事件记录
2017年10月28日，有同事在11点左右上报发帖验证码不出现的bug，突然想起前一天同事上报了回帖验证码不出的bug，感觉这两个是同一个问题，隐约意识到这个问题的严重性，便快速收拾了一下手头的工作（同事加班依赖于手头的工作），立刻着手解决。
- 确认问题；
- 确认问题相关的文件，但不要立刻修改（这次犯的错误）；
- 确认问题相关文件的修改记录，找到修改记录相关的执行人和业务；
- 初步快速（5分钟内）查看Arc Diff确认文件的修改范围；
- 随后立即跟相关的执行人沟通，最好由最后的修改文件执行人修改；
- 如果相关同事无法立刻修改，仔细阅读Arc Diff后修改，切忌根据当前的错误修改（通盘考虑）。
后记
最近反复跟同事“调侃”（宣讲）Debug三部曲，即上面的Debug检查清单，竟然真的收到了意想不到的效果，尤其昨天，竟然在多个同事身上命中了多次——简单想想，即使只把沟通和连接手机准备Debug的时间省掉，也会每次都省掉10分钟左右的时间，一天也只有48个是10分钟。
上面的清单还不足够完善，根据《清单革命》的理论，应该将关键步骤记录，同时是工作的一个最低标准，上面的步骤略显琐碎，后续逐步将其进一步更新。