如何成为零缺陷程序员？[关闭]

我的老板总是告诉我，一个好的程序员应该能够确保他或她更改的代码是可靠，正确和彻底的自我验证的；您应该完全了解所有结果以及更改将导致的影响。我已经尽力成为这样的程序员-通过一次又一次的测试-但是错误仍然存​​在。

我如何才能成为一个零错误的程序员，并且知道我的代码的每个字符都会引起什么影响？

根本不用编码。

这是您成为零错误程序员的唯一途径。

错误是不可避免的，因为程序员是人的，我们所能做的就是尽力防止它们，在错误发生时迅速做出反应，从错误中学习并保持最新。

对于不平凡的程序，零错误是不可能的。

可能会非常接近，但生产力会受到影响。对于某些高风险软件来说，这仅是值得的。该航天飞机的软件在我脑海中。但是他们的生产力每天只有几行。我怀疑你的老板想要那样。

该软件没有错误。它是完美的，就像人类所达到的那样完美。考虑一下这些统计信息：程序的最后三个版本（每行420,000行长）每个都只有一个错误。该软件的最后11个版本共有17个错误。

进行软件升级以使航天飞机可以使用“全球定位卫星”进行导航，这一更改仅涉及程序的1.5％或6366行代码。一项更改的规范需要运行2500页，比电话簿还厚。当前程序的规范填充30卷，并运行40,000页。

“零错误程序员”是一个沉默寡言的人，就像一个沉默的歌手一样，但是过去60多年的编程已经积累了一些智慧的提炼，这将使您成为一个更好的程序员，例如：

• 谦虚-你现在会犯错误。反复。
• 要充分意识到头骨的大小。谦虚地处理任务，避免像瘟疫这样的巧妙技巧。[Edsger Dijkstra]
• 对抗组合爆炸
• 摆脱可变状态（在可能的情况下）。是的，学习函数式编程。
• 减少可能的代码路径
• 了解（函数的）输入和输出空间的大小（大小），并尝试减小它们的大小，以使测试覆盖率更接近100％
• 始终假设您的代码不起作用-否则请证明！

TDD

TDD的要点是，如果没有要求使用该行代码的测试，则无需编写任何一行代码。要将其发挥到极致，您总是会通过编写验收测试来开始开发新功能。在这里，我发现编写黄瓜样式测试是理想的。

TDD方法至少具有两个好处。

• 编写所有代码来解决特定功能，因此不会产生不必要的过度生产。
• 每当您更改现有代码行时，如果您破坏功能，都会收到通知

它并不能证明零错误，因为那是不可能的（已经有无数其他答案指出了）。但是，在学习了TDD并变得熟练之后（是的，这也是一项需要实践的技能），我对自己的代码有了更高的信心，因为它已经过全面测试。更重要的是，我可以更改我不完全理解的现有代码，而不必担心会破坏功能。

但是TDD并不能完全帮助您。如果您不完全了解系统的体系结构以及该体系结构的陷阱，则无法编写无错误的代码。例如，如果您正在编写同时处理多个请求的Web应用程序，则必须知道您不能在多个请求之间共享可变数据（不要落入新手陷阱中以缓存可变数据以提高性能）。

我相信擅长TDD的开发团队所提供的代码缺陷最少。

问题是，错误是您不认识的东西。除非您具有某种编程语言/编译器的百科全书知识以及您的应用程序将在其中运行的所有环境，否则您确实不能期望产生100％无错误的代码。

您可以通过大量测试来减少错误的数量，但最终可能会出现一些无法解释的情况。乔尔·斯波斯基（Joel Spolsky）写了一篇关于错误修复的特别不错的文章。

是的，代码中永远不会有错误，但减少错误也不是不可能。为了避免减少代码中的错误数量，“愚蠢的，您总是会有错误”的态度只是为了解决这个问题。没有人是完美的，但是我们可以并且应该努力变得更好。在我自己的努力中，我发现以下几点很有帮助。

• 这不容易。你不会在一夜之间改善。因此，不要气and，不要放弃。
• 写得更少，写得更聪明。更少的代码通常是更好的代码。想要预先计划并尝试制作出色的设计模式是很自然的，但是从长远来看，仅编写所需内容可以节省时间并避免错误。
• 复杂性是敌人。如果这是一个晦涩复杂的混乱局面，那么少就不算数。代码高尔夫很有趣，但是很难理解，更难调试。每当您编写复杂的代码时，您都会面对很多问题。让事情简单明了。
• 复杂性是主观的。一旦成为更好的程序员，曾经很复杂的代码就会变得简单。
• 经验很重要。成为一名更好的程序员的两种方法之一就是练习。练习不是写您会轻松编写的程序，而是编写有一点伤害并让您思考的程序。
• 变得更好的另一种方法是阅读。编程中有很多很难学习的主题，但是仅通过编程就永远无法学习它们，您需要学习它们。您需要阅读困难的东西。除非您想通过清除灾难来学习，否则安全性和并发性是不可能通过仅编写代码来正确学习的。如果您不相信我，可以看看像gawker这样的史诗级安全问题站点。如果他们花时间学习如何正确地执行安全性，而不仅仅是做一些有用的事情，那将永远不会发生混乱。
• 阅读博客。那里有很多有趣的博客，它们将为您提供新颖有趣的方式来查看和思考编程，这将帮助您...
• 了解肮脏的细节。有关您的语言和应用程序各部分的晦涩难懂的细节非常重要。它们可能包含帮助您避免编写复杂代码的机密，或者可能是某些部分需要避免的错误。
• 了解用户的想法。有时，您的用户会疯狂地疯狂，并且会以您不了解和无法预测的方式与您的应用一起使用。您需要引起他们的注意，以了解他们可能尝试的陌生事物，并确保您的应用程序可以处理它。

我个人认为，争取无错误编程似乎更加昂贵（无论是时间还是金钱）。为了达到零错误，甚至接近零错误，您需要让开发人员进行全面测试。这意味着在提交任何代码进行补丁审查之前，对所有内容进行回归测试。这种模式并不具有成本效益。您最好让开发人员进行尽职的测试，并将深入的测试留给质量检查团队。原因如下：

• 开发人员很讨厌测试。是的，你知道。（我是一名开发人员！）一个好的质量检查团队将始终发现开发人员从未考虑过的优势案例。
• 开发人员擅长编码。让他们回到自己擅长的领域（以及通常无论如何都喜欢做的事情）。
• 质量检查团队可以一次发现与多个开发人员任务相关的错误。

接受，当您编写代码时，将会记录针对其的错误。这就是为什么要进行质量检查流程，这就是成为开发人员的全部原因。当然，这并不意味着您在写完最后一个分号后就立即提交内容。您仍然需要确保工作质量，但是您可以做得过高。

您可以列举几项始终能够在第一时间完成他们的任务而无需同行评审和/或测试的专业？

零错误？听起来您需要Lisp（遵循怀疑论路径，避免听音乐录影带）。

在主流编码环境（Java，C＃，PHP等）中，要实现无错误的代码非常困难。我将专注于在较短的受控迭代中生成经过良好测试和同行评审的代码。

保持代码尽可能的简单将有助于您避免错误。

确保您使用的是代码分析工具（例如FindBugs，PMD等），结合严格的编译器警告，这些工具将揭示代码的各种问题。记下他们在告诉您的内容，真正地努力理解错误的本质，然后采取措施更改编程习惯，以便以再次引入该错误的方式进行编码感觉不自然。

所有“完全不编码”。答案完全没有意义。另外，您的老板似乎绝对不是白痴！

我不记得有多少次见过程序员根本不知道自己的代码做什么。他们唯一的发展哲学似乎是反复试验（而且经常还会复制/粘贴/修改）。尽管反复试验是解决某些问题的有效方法，但通常您可以分析问题领域，然后根据对使用的工具的了解并应用一些非常具体的解决方案，而您只需一点点的纪律和勤奋就不会在您首次部署它之前，它不仅解决了问题，而且还解决了大多数极端情况（潜在错误）。您可以保证代码没有错误吗？当然不是。但是随着遇到或阅读的每个错误，您都可以将其添加到下次编写/更改某些内容时可能要考虑的内容。如果您这样做，那么您将获得有关如何编写几乎没有错误的代码的大量经验。-关于如何成为一个更好的程序员的大量资源，可以帮助您在旅途中...

就个人而言，我永远不会提交无法解释每一行的代码。每行都有一个原因，否则应将其删除。当然，有时您会假设所调用方法的内部工作原理，否则，您将需要了解整个框架的内部逻辑。

您的老板完全正确地说您应该了解您编写的代码对现有系统的结果和影响。会发生错误吗？当然是。但是，这些错误是由于您对所使用的系统/工具的不完全了解，以及每一个错误修复都可以更好地覆盖您。

正如其他评论已经正确指出的那样，没有没有漏洞的重要软件。

如果您要始终记住要测试软件，则该测试只能证明存在错误而不是不存在错误。

根据您的工作领域，您可以尝试对软件进行正式验证。使用正式的方法，您可以非常确定自己的软件完全符合规范。

当然，这并不意味着该软件完全可以满足您的需求。几乎在所有情况下都不可能编写完整的规范。它从根本上将可能发生错误的地方从实现转移到了规范。

因此，根据您对“错误”的定义，您可以尝试进行正式验证，也可以尝试在软件中查找尽可能多的错误。

不要写任何比“ Hello World！”更复杂的东西。或者，如果您确实告诉所有人，请不要使用它。

向您的老板询问此所谓的无错误代码的示例。

我同意其他观点。这是我如何解决问题的方法

• 找一个测试员。有关原因，请参见Joel测试。
• 广泛使用库；可能已经调试好了。我非常喜欢Perl的CPAN。

您可以努力成为一个零错误的程序员。每当我编写代码时，我都努力成为一个零错误的程序员。但是我不

• 运用多种测试技术（ATDD除外）
• 创建我们软件的正式验证
• 有一个单独的质量检查小组
• 对代码库的每次更改进行认真的分析
• 使用更倾向于安全和谨慎的语言

我不做这些事情，因为它们对我编写的软件来说成本太高。如果我做了这些事情，我可能会朝着零错误迈进，但这在商业上没有意义。

我创建了内部工具，这些工具可在我们的基础架构中大量使用。我的测试和编码标准很高。但是，这是一种平衡。我不期望零错误，因为我无法让人们将这样的时间花在一件事情上。如果我正在创建用于控制X射线机，喷气发动机等的软件，情况可能会有所不同。如果我的软件出现故障，生命将不复存在，因此，我们就无法做到这一点。

我将保证水平与软件的预期用途相匹配。如果您正在编写NASA航天飞机将使用的代码，那么零错误容忍度是合理的。您只需要添加一些额外的且非常昂贵的实践即可。

我认为，成为“零错误”程序员的第一步是改变您对错误的态度。与其说事情“发生”，“让质量更好的QA和测试人员”或“开发人员不擅长测试”，不如说：

错误是不可接受的，我会尽力消除它们。

一旦这成为您的态度，错误就会迅速消失。在寻找消除错误的方法的搜索中，您会遇到测试驱动的开发。您会发现很多书籍，博客文章，以及为更好的技术提供免费建议的人们。您将看到通过练习提高技能的重要性（例如编写Kats或在家里尝试新事物）。您将开始在工作中表现更好，因为您将开始在家工作。 而且，希望一旦您发现有可能编写优质的软件，您对工艺的热情就会增长。

从某种意义上说，你的老板是对的。可以编写接近零错误的软件。

但是问题在于，编写（几乎）零错误程序的成本非常高。您需要执行以下操作：

• 使用您要求的正式规格。正式的，例如在使用Z或VDM或其他一些数学上合理的符号时。

• 使用定理证明技术来正式证明您的程序已实现该规范。

• 创建广泛的单元，回归和系统测试套件和工具，以各种方式测试错误。（这本身是不够的。）

• 有很多人检查需求（正式和非正式），软件（和证明）。测试和部署。

您的老板极不可能为所有这一切付出代价...或者忍不住花所有时间完成所有事情。

我已达到“零错误”状态。我告诉用户这是一个未记录的功能，或者他们正在要求一项新功能，因此是一项增强功能。如果这些都不是可以接受的答复，我只是告诉他们他们不了解自己的要求。因此，没有错误。程序员是完美的。

以下是制作一个免费程序的步骤：

1. 除非您对功能有不明确的规范，否则切勿开始编码。
2. 请勿进行测试，或者如果您不做测试，则不要捕捉软件中的缺陷。
3. 将在测试，审查和生产中发现的缺陷的所有反馈应用于首先插入缺陷的过程和开发人员。发现缺陷后，立即将所有有缺陷的组件完全丢弃。更新您的清单并重新培训开发人员，这样他们就不会再犯这样的错误了。

测试只能证明您有错误，但是通常不能证明没有其他问题。关于反馈-如果您有制造硬币的硬币制造机，并且平均每10s硬币就有一个缺陷。您可以拿起那枚硬币，将其弄平并再次插入机器。回收的空白硬币将不那么好，但可以接受。每100枚硬币必须重新盖印2次，依此类推。修理机器会更容易吗？

不幸的是，人不是机器。为了成为一名优秀的，无缺陷的程序员，您必须花费大量时间，培训和迭代每个缺陷。开发人员需要接受正式验证方法的培训，而这些方法通常很难学习和实践。软件开发的经济学也与此相抵触-您是否愿意花2年的时间培训一个程序员，而程序员可以发现更少的缺陷，只是为了让他跳槽到另一位雇主，您会投入吗？您可以购买可以制作完美硬币的机器，也可以租用10个以上的代码猴子以相同的成本创建一堆测试。您可以将这个详尽的过程视为您的“机器”，即您的资产-投资于对优秀开发人员进行广泛培训不会带来回报。

很快您将学习如何开发质量可以接受的软件，但是您可能永远不会成为无缺陷的人，原因很简单，因为开发缓慢的完美代码的开发人员没有市场。

防御性程序：http : //en.wikipedia.org/wiki/Defensive_programming

如果有人遵循防御性编程的惯例，那么更改将很容易跟踪。将其与开发过程中严格的错误报告以及可靠的文档（例如doxygen）相结合，您应该能够准确地知道所有代码在做什么，并非常有效地修复所有出现的错误。

这可能是由于误解了一种好的方法，而不仅仅是泛滥成灾的结果吗？

我的意思是，您的老板很可能听说过“零缺陷方法”（请参阅第5节），而没有理会这意味着什么？
当然，管理层推迟新功能的开发是不方便的，因为您不应该放置一些错误……
当然，这威胁了他的奖金，因此您当然不会获得一个，因为“优秀的程序员不会有错误”

制作 bug 很好，只要您能够找到它们并修复它们（当然，在合理的范围内）。

软件测试的基本概念之一是，您绝对不能绝对确定程序是否完美。您可以永远对其进行验证，但这永远不能证明该程序是完整的，因为它甚至无法针对所有输入/变量组合进行测试，因此很快变得不可行。

您的老板似乎是“不懂编程的人之一，因为只是打字”

如果我们假设大型软件公司知道如何吸引顶尖的开发人员（例如零错误程序员），那么我们可以推断出微软的软件必须没有错误。然而，我们知道事实并非如此。

开发他们的软件，当它们达到一定程度的低优先级错误时，他们只需发布产品并稍后解决。

除非您要开发比简单计算器更复杂的工具，否则无法避免所有错误。甚至美国国家航空航天局也对其车辆和虫子有冗余。尽管他们进行了大量严格的测试，以避免灾难性的故障。但是即使如此，他们的软件中仍然存在错误。

错误就像人类的天性一样不可避免。

没有错误就像拥有100％安全的系统。如果系统是100％安全的，那么它绝对不再有用（它可能位于数以吨计的混凝土内部，根本没有连接到外部。既没有有线也没有无线。因此就像没有完美的安全系统一样） ，没有复杂的无错误系统。

我只看到关于我们是人类并且容易犯错误的答案，这是真的。但是我从另一个角度看到了您的问题。

我认为您可以编写无错误的程序，但是通常这些程序是您已经编写了10或12次的程序。第13次从头开始编写相同的程序时，您已经知道该怎么做：知道问题，知道技术，了解库，语言…… 在脑海中就可以看到。所有级别的所有模式都在那里。

对于我来说，这非常简单，因为我教编程。它们对我来说很简单，但对学生来说却很难。我并不是在说我在黑板上做过很多遍的问题的解决方案。我当然知道。我的意思是，大约300行的程序使用我非常了解的概念（我教的概念）来解决问题。我写这些程序时没有计划，它们只是起作用，我觉得我知道所有细节，我根本不需要TDD。我遇到了两三个编译错误（主要是错别字和类似的东西），仅此而已。我可以针对小型程序执行此操作，并且我还相信某些人可以针对更复杂的程序执行此操作。我认为像Linus Torvalds或Daniel J. Bernstein这样的人头脑清晰，他们是您可以找到的最接近无错误编码器的地方。如果你深刻理解事情，我认为你可以做到。就像我说的那样，我只能对简单的程序执行此操作。

我的信念是，如果您始终尝试执行远远超出您的水平的程序（我已经花了多年的时间来做），您会感到困惑和犯错。当您最终理解问题后，突然意识到解决方案无法工作的重大错误，必须进行如此复杂的更改，以至于您可能无法解决问题或使代码变得糟糕。我相信TDD就是针对这种情况的。您知道自己没有解决要解决的问题，因此将测试置于四处，以确保您拥有强大的基础。TDD并不能解决10,000英尺的视野。您可能一直都在使用完全干净的代码围成一圈。

但是，如果您尝试做一些新的但刚好高于您的水平的东西，则可能会使您的程序变得完美或几乎完美。我认为很难知道您的“知识前沿”中有哪些程序，但是从理论上讲，这是最好的学习方法。实际上，我从头开始大量重写程序。有人这样做，但是您需要大量的时间和耐心，因为第三次重复执行不重要的程序时，您不会像第一次那样感到兴奋。

因此，我的建议是：在您可以编写无错误的程序之前，不要以为您了解什么。然后尝试将您深deeply的两个概念合并到同一程序中。我几乎可以肯定，您会在第一时间找到正确的方法。最好的方法之一是重写非平凡的软件，这是第一次花费很多精力的事情（我现在正在使用Android应用程序执行此操作）。每次我重新开始时，我都会更改某些内容或添加一些东西，只是为了增加一点乐趣，而且我可以告诉您我变得越来越好了……也许不是没有错误，但是真的很自豪。

在编码过程中必须出现恕我直言的错误和突然的，错误的算法工件：它们激发并迫使代码进化。
但是，有可能（通常在进行一些测试之后）检查声明之前可能使用的每个变量，以处理可能出现的每个错误-使程序归零错误...直到收到要求考虑的功能请求当您讨论程序架构时，这是不可能的；）

也许更多地考虑您所得到的错误的性质。如果错误通常是次要的疏忽，那么专注于更好的测试和一点代码校对将有所帮助。

但是，如果错误往往是由于次优的编程决策所致，那么可能需要付出更多的精力进行更好的设计。在这种情况下，我认为可能过于依赖测试来提高软件的质量，因为对有缺陷的代码应用补丁只会使以后的维护变得更加复杂。一方面，您发现并修复的bug减少了，但是另一方面，您为将来的bug奠定了基础。

判断您是否有疏忽或设计方面的问题的一种方法可能是考虑需要花费多大的精力来修复错误。如果修补程序倾向于很大，或者您觉得对它们的理解不充分，那就说明可以改进的代码设计。

我认为，这归因于对代码的一种好习惯，您可以通过实践和回顾以及阅读有关类似问题的人来开发代码。

最终，完全不希望有任何错误是徒劳的，但是除非您已将其降低到一个较低的水平，否则尝试减少您的错误计数没有任何害处，然后这便成为您与任何发现者之间的权衡之举。您没有发现的错误。

如果我的意思是：“编写代码时零错误”->这是一个不错的目标，但几乎是不可能的。

但是，如果您的意思是：“交付的代码中的零错误”->可能，而我在这种环境中工作。

您需要做的就是：极高的代码质量和接近100％的测试覆盖率（单元测试+验收测试+集成测试）。

我认为最好的学习书是：GOOS。但是，当然，书还不够。您需要转到某个用户组并进行讨论。课程，会议等。零错误的质量并不容易。

首先，您需要一个对高质量真正感兴趣并愿意为此付出代价的老板。

程序员的解决方案：

• 停止编程。
• 建造一台机械计算机。
• 每5年更换一次，以免机械磨损。

用户解决方案：

• 停止使用计算机。
• 手动执行所有操作。
• 总是请第二个人仔细检查结果。

我同意，要成为一个零错误的程序员，您根本无法编程/编写代码。遇到和开发错误是每个程序员生活的一部分。没有经验丰富的开发人员可以亲切地说，他们从未遇到过代码中的错误。

与另一位工程师配对。编写失败的测试。让您键入的每个字符都可以通过测试失败。重构代码以使其更简单。编写另一个失败的测试，依此类推。