看“零Bug的代码是怎么炼成的？”后的感触

周末在家，看到码农翻身的一篇博客： 零Bug的代码是怎样炼成的？  感觉雪中送炭，于是结合自己的最近经历，写些感想。

现在在一个互联网+保险的创业团队里从事平台开发，当然大公司也还是有传统的保险业务，只不过各自有一亩三分地而已。接近年底，感觉业务纷至沓来，根本停不下来...开发任务自然也就产生很多倒排，每天都是战斗中，非常的互联网打法，还是很喜欢这样类型的工作，真希望能更早进入

在这一月中，经历了一次自己写的功能的上线，由于自己对新的开发框架的不熟、对业务还理解太浅，最主要是节奏快自己没有把控好，有些部分未覆盖测试就提交测试了导致了很多糟糕的经历，感觉很不好。项目组也进行了复盘，大家也都提出了自己的看法，听到鼎哥特别是磊明哥的见解，深感惭愧，必须好好学习，不断打磨自己的代码，并且多从他们身上学习。

现在对自己也提出这样的要求：在自己理解的业务范畴内，写代码阶段将bug都消灭，到测试团队时发现的bug几乎为零。

借用码农翻身中非常好的模式总结：

1、透彻理解需求

很多人看到需求后，想都不想就开始编码，这是有问题的。

作为一个码农，虽然不是需求分析人员，也要考虑下为什么要有这个需求，这个需求有哪些主干路径，有哪些分支路径，在老子里要形成一个图谱；

同时，假想成用户，用户会期待什么样的功能，如何使用这个功能；

2、良好的设计

把功能划分成接口良好的模块，让每个模块各司其职，又能依靠接口有效合作，能极大地减少bug的产生。

3、处理好边界条件

据说80%的bug是在边界条件时产生的，边界条件包括：

• 输入数据不合法
• 数组越界
• 调用方法抛异常
• 文件不存在
• 文件权限不够
• 调用其他系统时数据未能正常返回 （鼎哥所指的正确、错误、未知的第3种情况）
• 打不开数据库连接
• 数据库表在初始情况下没有值
• 运行时间过长导致超时

4、充分的测试

尽量做到所有方法都覆盖，而且是路径覆盖

5、考虑代码修改对别的模块的影响

一定要考虑代码修改对别人的影响，并且做回归测试；

有了别人的经验，重要的还是自己实践和体会，加油！