程序员为什么要一直改bug，不能一次性写好吗？
程序员为什么要一直改bug，不能一次性写好吗？
－－－－－
网友解答：
－－－－－
代码出现BUG很正常，我们可以最大程度的避免BUG的出现，就像偏差一定存在、可以无限逼近正确，但是错误却是可以通过好的工作方法、编码规范、工作习惯来避免、杜绝。程序员开始编码工作，不管整个项目开发还是部分代码扩展，都一定是源于实际需求：
第一步明确需求的来龙去脉、然后确认清楚理解需求，确认是否理解需求的最佳实践就是写好需求说明、概要设计，然后跟干系人\u002F负责人确认，而不是口头上说理解了，甚至都不复述确认。
第二步对概要设计中技术点进行验证、细化设计，在细化设计过程中对工程名、类名、代码调用框架、方法名、成员变量和关键变量名进行设计，再跟干系人、负责人进行确认。
第三步，良好的编码习惯、编码规范是非常重要的，也是直接体现程序员的基本素养，清晰的思路、良好的编程习惯是代码高质量的重要保障。
最后一步是代码测试，程序员交付的代码一定要自己保障单元测试是能够闭环通过，然后开发人员交叉测试。接着交付给QA测试部门进行测试，因为“灯下黑”有些问题程序员自己很难发现；对于较大幅度代码调整，还要进行回归测试、对所有功能、在各种环境下进行测试，回归测试工作量通常较大。
好的软件产品是设计出来的、开发出来的、更是项目实战中用出来的，是不断完善、测试、交付使用迭代出来的，不可能一蹴而就。工作方法、代码规范、编码习惯、测试把关保障代码质量至关重要的，写需求、设计、测试文档不是教条主义、更不是浪费时间，跟聪明愚钝智商都没有什么关系，但是很多的程序员不够重视、内心到行动都在抵制、抗拒，然后让现实一次又一次的打脸，慢慢成长开始重视起来，深刻理解“只做一次、一次做对”是最省时间的，然后再苦口婆心或者雷厉风行用自己的血泪史或者规章制度来教导、约束新进的程序员。
－－－－－
网友解答：
－－－－－
程序员的日常三件事：写Bug、改Bug、背锅。这看似是一个调侃，但实际上确实大部分程序员日常工作的真实写照！没有bug的程序是不存在的，你说没有，是因为你没有找到，足够长的时间，一定能找到的。
软件工程的方法论中，要求软件开发者尽可能多地在软件测试阶段发现bug，而不是交付之后。但是楼主说的能不能让软件开发出来没有bug，我觉得把下面这几个事情做好，尽量减少BUG，而不是没有BUG。
1、花尽可能多的时间，和客户沟通软件需求，了解每一项需求的用意。
2、确保软件需求减少软件需求变更，因为很多情况下一个需求的变化，程序会带来很多问题，有可能连底层结构都需要跟着一起变动。频繁的需求变动，加上开发周期和成本的约束，带来的结果就是软件质量的不可控。
3、确保软件测试质量，完成全覆盖测试，设计系统需要的全部用例并保证全部通过。
把事情一次性做对确实是很有必要的，谁也不想没事给自己挖几个坑，但这需要有缜密的思维了，而我相信，这个世界还是粗心的人多点。程序不是一蹴而就地做出来的，Bug也不是一时半会能改完的。
－－－－－
网友解答：
－－－－－
网上有一个流传的传说：
别人编译运行代码是为了检查有没有bug，Jeff Dean（谷歌AI部门的负责人）是为了检查编译器有没有bug。
当然这只是传说，没有验证。
程序员为什么要一直改bug？
bug为什么叫bug？
其实第一次记载的bug还真的不是程序员写出来的。
那是一次在程序员在为计算机做测试的时候，突然发现计算机停止工作，检查后发现原来是因为一只虫子（英文是bug）爬进了计算机，导致计算机继电器出错进而让计算机停止了工作，因此计算机错误从此被称为bug。
不只是程序员要改bug
会犯错是人类的天性，因为人类不是完全精密的仪器，记忆会错乱，身体控制达不到100%，认识也无法做到全知，所以程序员会写出bug，播音员会念错字，作家会写错字，我们会记错人名。
而且bug也不一定全是坏事，这一点在科学界尤其如此，因为科学本身就是一个不断试错的过程。比如拯救了无数生命的青霉素的诞生，也是在研究过程中失误才发现的。
也有故意制造bug的。比如我有一次使用一个第三方库连接服务器，但是后面发现这个库在连接因为某些问题中断后重新连接却连接不上，这时候要换库会很麻烦，所以我写了一个bug，在连接中断的时候崩溃整个服务然后重启，这样就可以连上了。
bug都有哪些种类
我来列举一些bug的种类：
逻辑性bug：这种bug通常是程序员思考的不够缜密和全面导致的。
代码相容性bug：通常一个程序不是由一个程序员完成的，多个程序员写的代码之间可能会因为某些意识和理解不同导致bug发生。
性能导致的bug：程序写出来后可能会在不同的设备上运行，在某些性能差的设备上可能因为性能不够导致程序出现bug。
环境性bug：不同的环境也会导致bug的产生，比如早期卫星上的程序很多出现bug的原因是因为太空辐射不一样，使得硬件受到影响，进而导致程序运行得到的结果和预期不同而出现bug。
所以说，程序员很难一次性写出没有bug的程序。
但是我们程序员也不因此就对bug包容了，虽然不能保证没有bug，但是我们应该对自己有要求，对bug零容忍～
－－－－－
网友解答：
－－－－－
不能。不能一次写出没有bug的代码，也不能一次修复完全，这和一口吃不成胖子是一个道理。
程序中的bug有不同的种类，原因也各不相同，三六九等。可以说是“不同水平”的bug，一定程度上反映了软件工程师的水平。
1，代码级别的bug
比如变量错误、计算公式错误，还有常见的页面显示、文案信息等错误。
这类问题容易修复，并且能够通过代码检查、功能测试等方式减少甚至避免。
2，逻辑错误
代码实现和业务需求不一致，比如计算每月的最后一天，因为每月天数不固定，可以使用下个月的1日减去一天，得到本月最后一天。
这类bug经常由于测试覆盖不到而较难发现，往往需要编写单元测试。
3，调用模块错误
随着应用系统功能越来越复杂，开发时会根据系统功能进行模块划分，然后通过接口调用协作。
不同模块的接口、数据、还有版本不一致时，会产生一些“复杂”的bug，不仅难于发现，也较难修复，常常需要配合单元测试、自动化测试，并在修复后进行回归验证。
4，系统集成bug
拿近期发生的中行原油宝穿透事件举例，中行原油宝在提交价格时，验证负数价格无效，所以也就禁止了进一步提交操作。从单个系统看，这样做是没问题的。
但是还有交易所系统，它是允许负数价格的，这就悲剧了。
多个系统间的bug需要通过完整的用例设计来避免，比如中行原油宝，测试要覆盖到交易所系统的完整用例。
－－－－－
网友解答：
－－－－－
我记得这个问题，我写过。而且我还专门写了一篇文章来回答这个问题。
看看我当时是有多无聊！哈哈……今天再来回答一遍这个问题。
这个问题一看就知道不是程序员提问的，程序员都知道是怎么回事。一定是一个外行人的提问。
所以，对外行解释程序中 Bug ，不能说的太专业，我讲两个故事，外行人看了就明白了。
第一个故事：为啥你家装修完了，你总是不满意呢？
很多装修过房子的人都知道，装修房子的过程有多辛苦，多操劳，装修完了总是还有很多不满意和缺憾。
从交房的那一刻起，你就开始寻找设计师（跟设计软件的设计师异曲同工），开始根据你家房子的尺寸和构造，朝向和你平时的生活习惯，储藏东西的多少，进行房主的需求挖掘，这里相当于软件的产品经理。设计师根据你的需求设计工程图纸和设计效果图（这里相当于软件设计完了）。你感觉设计的不错，好开工，水电工，瓦工，木工，油漆工，开始进场，根据效果图施工（这里的各种工互相配合，互相衔接，相当于软件中的前端和后台等工程师敲代码配合开发）。
施工完了，得有工程监理和业主验收，相当于开发中的测试。
到这里看起来很正常，但是，可能水电改的有点瑕疵，少了一个插座，你不满意了，可能油漆有的地方涂抹不均匀，你也不满意了，可能木工打的柜体，磕碰了一点，你也不满意了。这就是程序中的 bug 。
你怎么不说，装修不能给我一次性装修好呢？看看有多少工程衔接，各种工种配合，你能保证一点问题没有么？生活中处处都有不完美的地方，干什么活有十全十美的东西呢？
你这只是验收（相当于开发中的测试）的时候发现的问题，等你真正入住的时候，真正生活的时候，可能还会发现各种当初对设计不满意的地方，很多东西等真正用的时候，才发现当初应该这么设计（这也算 bug）。
第二个故事：不按常理出牌
你在使用一个产品的时候，人家明明有说明书，有使用步骤，你作为用户，就是反着操作，比如：使用高压锅的时候，明明得先放气，才能掀开锅盖，你非先掀开锅盖。意外发生了，嗖一下炸了！这就是程序中的崩溃，属于大 bug 。
人家设计程序的时候是有一套逻辑和操作步骤的，但是呢，用户不清楚，就知道瞎按，瞎操作，众口难调，用户几十万的产品，每个用户操作流程都不给你按照设计的来操作，就容易导致程序出 bug ，甚至崩溃！你说程序员能把所有的情况想到么？
还不是尽量想，想不到的等出了问题才能知道，才能修改！
最后，编程哪有想象的那么容易啊！作为程序员，自编程伊始，Bug 就会如影随形，因为它就是你的影子。Bug 就是软件的影子，和软件就是与生俱来的，是不可逃脱的好 CP，有着难舍难分的好感情。Bug 无处不在，对于程序员的酷爱，超越程序猿的老婆，它对于软件的痴迷，比程序猿还要厉害，即使再牛逼的程序猿也逃脱不了 Bug 的魔掌。
－－－－－
网友解答：
－－－－－
我是
路飞写代码
，十年前端开发经验，是一名资深程序员，可以说在程序Bug这个问题上还是有自己的一些深得体会的。
在细致的程序员在需求面前一切成空
可以说笔者这十几年做的项目来看，很少有将需求捋的特别细致的，也就是说总是开发中扩充需求，需求中夹着着开发这样一步一步往前推进的。
这就会导致什么情况呢？需求不确定，也就是说每一个需求其实在真实的场景之下或许并非我们所想的那样，或许我们想到了第一个层面，其实还有第二个层面，也就是需求不全面。
那么我们在编程的时候就会只想到了一个方面，而并没有覆盖所有的方面，也就是程序存在了Bug，那么在进行穷尽测试的时候，此时Bug就会显现出来，这是其一。
并非程序员要一直改Bug，只是为了完善程序
甚至有一些Bug其实在程序员看来是非常不必要的，就比如用户没有按照操作手册来进行相应的步骤，导致出现了错误，那么其实在普通人看来就认为这是一个Bug。
那么其实这根本不是一个Bug，而是易用性的问题，那么既然用户提出了这样的要求，那么程序员也就必须去更改操作，或者增加限制，让程序的执行路径有且仅有一条，这是其二。
在资深的程序员也无法一次性写出没有任何Bug的程序
无论你多么资深，你也无法写出一个没有任何Bug的程序，当然了笔者这儿指的是稍微复杂点的程序，肯定不包括我只写一句打印的语句。
因为其实编程做久了，几乎所有的语言都大同小异，而不变的其实编程的思维，很多编程语言其实都是相互借鉴参考。所以并非不是程序员不想一次性写出不再改变的代码，只是因为方方面面，比如需求，比如易用性，比如用户的奇怪诡异的要求，这些让程序员的Bug永远在进行当中。
今天的回答就到这儿了，我是
路飞写代码
，前端资深工程师，如果有前端方面的疑问，欢迎关注并私信我，我会进行比较专业的解答。
－－－－－
网友解答：
－－－－－
你为什么要分三餐吃饭，不能早上3秒钟把全天饭吃了吗？
这样多省时间[灵光一闪]
－－－－－
网友解答：
－－－－－
兄弟，楼一次盖好了就行了，为什么过几年就有下水堵塞的情况啊，直接给下水管道设计的足够粗不堵不就行了。其实如果什么事都这么简单就好了，街上的路一次性修好就行了，为什么过几年就要重新铺下路面，衣服买一件就好了一辈子不换就可以了，为什么每年都要买，这个道理也是一样的。谁不想做一个完美的设计，可以一劳永逸，人的需求是一直变的，有需求提出的新bug，还有遗漏的问题后来暴露出来的，新的需求例如：原来屋子里住10人，后来进了个传销组织，直接让屋子里住了20个人，下水道管子比较细就堵了，这就是原来的需求满足不了了。因为一个开关一直不用，当时可以，后来因为不按照正常的操作私拉了一个，导致一个开关不能用了，这就可能是遗漏的bug。反正人的欲望是一直在变的，每个人的习惯也不一样，完全按照操作手册可能没问题，大概一创新可能系统就挂了，就产生了所谓的【bug】。
－－－－－
网友解答：
－－－－－
你能一辈子不犯错吗
－－－－－
网友解答：
－－－－－
你这个问题并没什么技术含量，但我看评论大多长篇大论，且有违主题，故有必要做下回答：
首先，bug呢，作为程序员，即
软件开发工程师
，也不想有，因为有的话，这对自己的绩效考核有负面影响。
至于你说的想一次性写好，那是很难的，因为人不是机器，总会犯错，而程序员一犯错，就是bug了，很多都是编写程序时，思虑不缜密、用法不规范所导致的。
其实IT行业里边有个职业——
测试开发工程师
，是专门为程序员的程序做测试的，很多都是细心仔细的小姑娘，她们也尽力去发掘程序中隐藏的bug，督促开发者及时修复bug，但是还是有bug出现。
此外，IT行业里边有个职业——
架构师
，一般都是些工作多年的资深开发，他们在程序上线前也做了代码的review，对代码的性能、规范等方面做了检查，督促开发者写出健壮的代码，但是程序中依旧有bug出现。
以上，经过多个流程才上线的应用，还是有bug的出现，真的是尽力了，人不是神，除非成神了，才能写出的代码，一步到位。
－－－－－
网友解答：
－－－－－
bug是计算机程序的瑕疵。世界上有什么东西是完美无暇的呢？
程序中的瑕疵是怎么产生的呢？
需求的瑕疵
程序设计是为了满足需求的，需求的设计和定义是一个很复杂的过程。人们在解决复杂的问题的时候，是会考虑不周的，那么就会产生瑕疵。有时候甚至会产生不同需求的前后矛盾。
为了把复杂的问题通过分而治之的方式简化处理，人们发明了敏捷开发。边实现，边应用，边改进，边完善。从而减少需求的瑕疵。
设计的瑕疵
有了需求然后就会设计解决方案，包括架构设计和接口设计。设计中也会产生瑕疵。有些是因为对需求理解的偏差，有些是因为考虑不周。有些问题甚至明知道存在不足，也没有更好的办法。或者完美的方案需要大量的资源和时间，然而因为不经常发生，所以投入产出的回报不高。
完美的设计方案也是一步一步改出来的。
编程实现的瑕疵
程序员在理解了需求和设计以后开始编码实现。这个时候也会因为理解的不足产生错误。程序里面包含大量的逻辑实现，充满了判断和选择，就算没有理解的偏差，也会出现漏洞。通过充分的单元测试可以发现大部分的漏洞，但是不可能发现全部的漏洞。尤其是在项目很紧的时候，程序员加班加点赶工实现，有时候，没有时间写充分的测试，只能测试最常见的情况之后就得匆匆上线。
优秀的程序员，有着清晰的逻辑思维，良好的编程习惯，深厚的技术功底，认真负责的工作态度，写出的程序bug比较少，但也是不能做的完全没有。
------------------
推荐阅读：
刚退休，想换一台适合自驾游的中大型SUV，有什么合适的车型？
