程序员为什么要一直改bug，不能一次写好吗？ _程序员

代码和bug如影随形，每一个应用程序都有bug 。从理论上讲，因为测试无法覆盖所有情形，所以存在bug的可能性一直有。
水平再高的工程师，也无法一次写出没有bug的代码，更不能一次性修复所有bug，这和不能一步登天是一个道理。
从另一个角度讲，程序中的bug有不同的种类，原因也各不相同，甚至可以划分为三六九等。可以这么说，"不同水平"的bug，一定程度上反映了软件工程师的专业水平。

文章插图

1，文案bug这类bug大多可以避免，原因多是因为粗心、没有认真检查，或者多次反复修改文案造成。

文章插图

2，代码级别的bug代码中常见bug很多，比如变量引用错误、计算公式错误，还有常见的异常处理等错误。
这类问题容易修复，并且能够通过代码检查、功能测试等方式减少甚至避免。
初级工程师写代码时常犯这类错误，随着水平提高和经验积累，代码质量逐步提升，bug也就随之减少。

文章插图

3，逻辑错误实现业务逻辑时，如果代码和业务需求不一致，比如计算每月的最后一天，如果使用30天或者31天，都会引起错误，因为每月天数不固定。
那么应该如何避免这类bug，又不至于将代码变得过于复杂呢？经常使用一些数学算法、公共代码库或者第三方开发包等。比如上个例子，可以使用下个月的1日减去一天，得到本月最后一天。
这类bug经常由于测试覆盖不到而较难发现，比较好的方式通常采用单元测试，覆盖足够的业务场景，从而保证代码逻辑符合预期。

文章插图

4，调用模块错误开发应用系统时，经常调用一些功能模块，比如Python开发时使用的urllib，还有自己开发的应用服务，比如订单配送管理。
应用上线后，业务逐渐丰富完善，系统功能越来越复杂，常常进行模块服务划分，然后通过接口调用协作。
不同模块的接口、数据、版本不一致时，会产生一些bug，不仅难于发现，而且较难修复。这类问题常常需要配合单元测试、自动化测试，并在修复后回归测试。
为了提高工作效率，自动化测试工具配合构建服务器，在每次代码提交时或者每天定时构建时，自动触发任务，确保测试用例覆盖业务场景。

文章插图
【程序员为什么要一直改bug，不能一次写好吗？】
5，系统集成bug2020年4月22日，发生了令人不可思议的中行原油宝穿透事件。原油宝交易系统在提交价格时，对负数价格进行验证，判定无效，所以也就禁止了进一步提交操作。从单个系统看，这样做是没有问题的。
但是还有CME的WTI原油期货交易系统，它是允许负数价格的，这就悲剧了。
4月20日，因为疫情恶化，美国原油期货合约结算价格暴跌，报出了-37.63美元/桶的历史性负数，下跌306%，引爆全球市场。根据中行4月22日公告，旗下理财产品原油宝将按照-37.63美元/桶的官方结算价定价。
这意味着投资者所有本金都将荡然无存，还要倒欠银行钱。
多个系统间的bug需要通过完整的用例设计来避免，比如中行原油宝，测试要覆盖到交易所系统的完整用例。