it-swarm.cn

如何成为零缺陷程序员?

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

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

168
Elaine

完全不编码。

这是您成为零缺陷程序员的唯一途径。

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

365
wildpeaks

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

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

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

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

124
CodesInChaos

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

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

TDD

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

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

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

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

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

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

25
Pete

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

您可以通过大量测试来减少错误的数量,但最终可能会出现一些无法解释的情况。 Joel Spolsky在 bug-fixing 上写了一篇特别好的文章。

19
user7007

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

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

零错误?听起来像 您需要LISP (遵循怀疑的路径,并避免播放音乐视频)。

在主流编码环境(Java,C#,PHP等)中,要获得无错误的代码非常困难。我将专注于在短时间受控迭代中生成经过良好测试和同行评审的代码

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

确保您正在使用代码分析工具(例如 FindBugs[〜#〜] pmd [〜#〜] =等),再加上严格的编译器警告,将揭示代码的各种问题。记下他们在告诉您的内容,真正地努力理解错误的本质,然后采取措施更改编程习惯,以便以再次引入该错误的方式进行编码感觉不自然。

8
Gary Rowe

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

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

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

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

8
Sebastien Martin

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

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

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

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

8
Patrick Klug

正如其他评论已经正确指出的那样,没有没有漏洞的非平凡软件。

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

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

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

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

7
FabianB

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

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

6
JeffO

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

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

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

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

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

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

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

5
dietbuddha

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

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

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

4
Darren

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

但是问题在于,编写(几乎)零错误程序的成本(过高)。您需要执行以下操作:

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

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

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

  • 许多人们查看需求(正式和非正式),软件(和证明)。测试和部署。

您的老板极不可能为所有这一切付出代价...或忍不住花所有时间来做。

2
Stephen C

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

1
angryITguy

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

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

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

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

很快您将学习如何开发质量合格的软件,但是您可能永远不会成为无缺陷软件的作者,原因很简单,因为开发速度慢,没有开发完美代码的开发人员市场。

1
Alexei Polkhanov

如果我们假设大型软件公司知道如何获得顶尖的开发人员(例如零错误程序员),我们可以推断出微软的软件必须错误。然而,我们知道事实并非如此。

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

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

错误是不可避免的就像人的天性会出错一样。

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

0
Robert Koritnik

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

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

0
Jason McCarrell

这可能是对良好方法论的误解的结果,而不仅仅是普通的骨头问题吗?

我的意思是,您的老板有可能听说过 “零缺陷方法” (请参阅第5节),却没有理会这意味着什么?
当然,管理人员推迟开发新功能很不方便,转而使用不应该插入的错误...
当然,这威胁了他的奖金,所以您当然不会得到一个,因为“好的程序员没有错误” ...

只要可以查找错误制作错误, 修复它们(当然是在合理范围内)。

0
AviD

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

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

0
SpacePrez