开发过程中如何避免踩坑？

互联网公司的业务需求很多，前人挖坑后人填，后人填坑不慎又掉进更深的坑。没有人愿意走坑坑洼洼的路，但是常在河边走，哪有不湿鞋的道理，如何避免掉坑，是每个职场上生存的人都该学习和思考的。

开发阶段

问题总是暴露的越早越好，能在开发阶段就发现bug是最理想的情况。我从"上线检查checklist"中领悟到了"开发设计checklist"，即在设计和实现的时候要考虑到业务系统的复杂性，尽量把新代码的影响范围控制在最合理、最小的范围里，从源头上降低隐藏bug对系统的负面影响。

 

Code Review阶段

当局者迷旁观者清，但是当大家都很忙的时候，"同僚互审"机制就很难起到从代码中发现隐藏BUG的作用。绝大多数的BUG都是在测试和生产环境中暴露出来的，因此不要对CR抱有太多幻想，能在CR阶段发现的问题通常都是小问题。

其实CR的真正作用是提醒开发者去思考自己的代码是否有问题，就像下中国象棋一样，当你面对棋盘、棋子反复思考推演时，是可以发现目前存在的问题并做出弥补的。

 

测试阶段

互联网后端系统有一种很重要的测试叫做无diff测试，即在某个功能上线之前，验证线上版本和开发版本是否存在业务结果方面的差异。对于隐藏BUG，无diff测试的数量一定要足够大，因为这是距离上线的最后一道防线了，测试样本覆盖面越广，越有利于发现隐藏BUG。

 

上线观察

带有BUG的版本上线之后，不一定马上就会暴露问题，暴露出的问题现象有时候会带有一定的迷惑性，很容易引起各种猜想，这也是隐藏BUG的危害厉害之处。

刚暴露问题的时候是立即回滚线上版本，进行快速止损的最好时机，但是需要发现问题的人有非常清醒的认识，即回滚止损的意识。开发人员不要恋战，更不能拖延，“回滚”二字要常记心头。人不能重生，但是系统可以回滚。

 

就像学轮滑和滑雪先学会摔倒时保护自己不受伤一样，程序开发过程中，“回滚意识”、“无diff测试”、“自身Code Review”、“设计时缩小影响范围”等技巧和经验是一定要牢牢掌握的。

掉到坑里很不爽，爬出来，往前看，以后走路吸取教训。

---

金句分享

我有幸学过并在工作中用过十几种编程语言，而且还为其中一些写过书。我觉得，编程语言就像各种型号的汽车——它们各执所长，帮助我们掌控平台的方向。

——摘自《Scala实用指南》，作者是美国的文卡特博士

解读：作者谦虚严谨，又不像一般的老外喜欢长篇大论，书如其名，非常实用的一本Scala入门技术书。