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

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

评论

除了我之外,没有人真正在第一时间创建完美的代码。但是只有我一个人。 ―技术讲座:Git上的Linus Torvalds,Google,2007年8月15日izquotes.com/quote/273558

相关:为什么IT行业无法像其他行业一样快速交付大型,无缺陷的项目?

没有0-bug编程之类的东西。阅读数学家Godel以了解原因。
目标错误,请参阅:yegor256.com/2015/06/18/good-programmers-bug-free.html

#1 楼

根本不要编写代码。

这是成为零错误程序员的唯一方法。错误是不可避免的,因为程序员是人,我们只能做尝试我们会尽力防止它们发生错误时迅速做出反应,从我们的错误中学习并保持最新。

评论


+1后续活动:或者您可以成为非编码(象牙塔)建筑师,但仍能获得丰厚的报酬!那是最好的。

–马丁·威克曼(Martin Wickman)
2011年1月29日19:54

错误是人类的,要修正您的错误。

–穆德莱特(Ward Muylaert)
2011年1月29日23:11

我曾经有一个受到老板青睐的同事,因为她一直以来的bug数量很少。她是怎么做到的?很简单,她将自己不想要的错误分配给其他人,并且始终采用最简单/最小的功能。

–托比
2011年1月30日下午6:31

我不知道是谁先说的,但是,“如果调试是消除bug的过程,那么编程就必须是放入bug的过程。”

–布鲁斯·奥尔德曼(Bruce Alderman)
2011-1-30在7:03

更好的是:成为老板,让您的下属感到痛苦,而无需承担任何责任。

–biziclop
2011年1月30日19:18

#2 楼

对于一个平凡的程序来说,零错误是不可能的。
可能会非常接近,但是会降低生产率。对于某些高风险软件来说,这仅是值得的。我想到了航天飞机软件。但是他们的生产力每天只有几行。我怀疑您的老板想要那样。

该软件没有错误。它是完美的,就像人类已经实现的那样完美。考虑一下这些统计信息:程序的最后三个版本(每行420,000行)每个错误仅一个。该软件的最后11个版本总共有17个错误。
进行软件升级以使航天飞机可以使用“全球定位卫星”进行导航,这一更改仅涉及程序的1.5%,即6,366行码。一项更改的规范需要运行2500页,比电话簿还厚。当前程序的规范涵盖30卷,并运行40,000页。


评论


不是不可能。但是可能性很小。

–比利·奥尼尔(Billy ONeal)
2011年1月30日,下午1:20

是什么让您认为FB没有错误? Facebook的安全和隐私模型是一个巨大的错误。例如,由于安全漏洞,Facebook老板Facebook帐户上周遭到黑客入侵。

– Stephen C
2011年1月30日,下午2:06

@Elaine Facebook的理念是“快点做事”(geek.com/articles/news/…),他们遇到了无数错误(facebook.com/board.php?uid=74769995908),包括我运行的许多错误进入我自己。 Twitter也不例外,以经常宕机(engineering.twitter.com/2010/02/anatomy-of-whale.html)和“跟随错误”等错误而闻名(status.twitter.com/post/587210796 / ... )。

–叶夫根尼·布里克曼(Yevgeniy Brikman)
2011年1月31日下午5:39

不要忘记移动的球门柱。 PerfectProgram 1.0中的功能可能是2.0中的错误

–卡洛斯
2011年1月31日,12:41

@CodesInChaos:该理论认为,存在无法证明其行为的程序。并不是说不可能证明所有程序的行为。我猜想大多数通用程序都是可证明的类型,并且声称“由于停顿问题,我的代码不可能没有错误”是对理论的错误应用。

– Endolith
13年1月23日在18:16

#3 楼

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


谦虚-您现在会犯错误。反复。
要充分意识到头骨的大小。谦虚地处理任务,并避免诸如瘟疫之类的巧妙技巧。 [Edsger Dijkstra]
战斗组合爆炸

摆脱可变状态(在可能的情况下)。是的,请学习函数式编程。
减少可能的代码路径数量
了解(函数的)输入和输出空间的大小(大小),并尝试减小它们的大小以获取接近100%的测试覆盖率
始终假设您的代码无法正常工作-否则请进行证明!


评论


我很高兴证明自己的代码可以正常工作……但是测试只能证明事实并非如此。您是在谈论正式证据还是在设想调试任务?

– Matthieu M.
2011-1-30在16:40

这个线程的第一个有用的答案。 @Matthieu:对于两个字节的每种可能的组合,您可以证明一个函数将返回正确的结果(例如:max),该结果又是一个字节。您可以有两个或更多这样的函数,现在可以将它们链接起来,并获得大量此类函数的可能组合,这些组合只会再产生一个字节。只能证明错误的想法是错误的。受欢迎,但错了。

–用户未知
2011年3月13日下午4:19

@Matthieu M .:测试证明事情正在按您的预期进行。如果您可以证明所有项目都按预期方式工作,那么从那里可以证明您正在处理意料之外的输入行为。一旦确定了该行为的含义和应有的行为,就可以为其编写新的测试。现在,这已成为您预期行为的一部分。

–deworde
2011年10月21日在10:49

@deworde:我了解测试的想法,但是,除了利基情况外,我已经完成的大部分实际工作都无法进行详尽的测试,仅仅是因为可能的组合数量太大(而且我甚至没有添加时间问题)。因此,除了特殊情况外,测试仅进行了很长时间(检查至少正常情况下通过还是有用的!)

– Matthieu M.
2011-10-21 17:06



“避免像瘟疫这样的聪明把戏”-仅此一项就可以做出很好的回答。确实如此-很棒。

–BЈовић
2014年5月21日在11:36

#4 楼

TDD

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

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


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

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

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

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

#5 楼

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

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

评论


+1。用扭曲姐妹的话说,你不知道肯定会伤害你/看不见会使你尖叫。

–工程师
2014年7月1日上午10:07

#6 楼

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


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


#7 楼

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


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

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

您可以说出多少个职业,他们总是在第一时间完成任务而无需同行评审和/或测试?
/>

#8 楼

零错误?听起来您好像需要Lisp(遵循怀疑的态度,避免观看音乐录影带)。

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

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

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

评论


有时,错误就像生活在里面的隐藏的怪物一样,它们在我反复测试和自我代码审查期间会隐藏起来……但是,当我进行同行评审时,我发现这些怪物是难以置信的可见的,并突然跳了起来。真的很奇怪仅仅依靠人类的“眼睛”和“大脑”似乎不可能碰到没有错误的线。单元测试不适用于所有情况。代码分析工具?听起来令人兴奋,我从未使用过,我将在该领域进行研究。

–伊莲
2011-1-30在1:54



我会说您需要Ada,但是Lisp更加有趣。 ;-)

–Orbling
2011年1月30日,下午2:40

@Elaine我工作的地方是Java环境,并且只有通过Findbugs和PMD传递的代码才能与团队共享。新的团队成员经历五个阶段:拒绝,愤怒,讨价还价,沮丧和接受。之后,他们再也不会回头。

–加里·罗(Gary Rowe)
2011年1月30日9:01

@加里·罗(Gary Rowe),我理解那些反应,大声笑,我去过一家公司的质量保证部门。那里的员工每周检查一下该周产生的所有代码,以查看每一行代码是否符合“规则” '(我不知道他们是否使用了诸如Findbugs / PMD之类的工具),但这听起来有点像您所要做的步骤。

–伊莲
2011年1月31日在1:09

@加里:我没有争论,但是我工作过的几个地方都将样式违规视为等效的错误。而且他们倾向于使用样式规则,例如“每个类都必须声明包含包和类名的静态字段CLS_PKG和CLS_NAME”。我通常支持编码标准,但是当它们演变成这样的东西时就不支持!

– TMN
2011年2月1日14:45

#9 楼

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

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

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

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

评论


“有了您遇到或阅读的每个错误,您都可以将其添加到下次编写/更改某些内容时可能要考虑的内容中”,这是一个很好的观点。我创建了一个与我所见或编码的错误相关的google文档,仅用于此目的。

–本
2011-12-09 20:28

#10 楼

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

如果要始终牢记要测试软件,那么测试只能证明存在错误而不是错误。

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

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

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

#11 楼

不要写任何比“ Hello World!”更复杂的东西。或者您是否告诉每个人不要使用它。

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

#12 楼

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


找一个测试人员。请参阅Joel测试以了解原因。广泛使用库;可能已经调试好了。我非常喜欢Perl的CPAN。


评论


…但是,如果您使用库,请确保它们的错误不会拖累您(例如,通过提供源,以便您可以对其进行审核或在需要时自行修复错误)。

– millenomi
2011-1-30在8:44

#13 楼

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


使用多种测试技术(ATDD除外)
创建对我们软件的正式验证
拥有单独的质量检查团队
对代码库所做的每次更改都要进行严格的分析
使用一种更倾向于安全和谨慎的语言

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

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

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

#14 楼

我认为,成为“零错误”程序员的第一步是改变您对错误的态度。与其说事情“发生了”,“变得更好的质量检查和测试人员”,也不是说“开发人员吸吮测试”,而是说:

错误是不可接受的,我将尽我所能消除他们。

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

#15 楼

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

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


使用您的要求的正式规范。形式化,例如使用Z或VDM或其他数学上合理的符号。
使用定理证明技术来正式证明您的程序已实现该规范。
创建广泛的单元,回归和系统测试套件并利用测试每种方式的错误。 (这本身是不够的。)
有很多人在审查需求(正式和非正式),软件(和证明)。测试和部署。

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

#16 楼

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

#17 楼

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


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

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

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

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

评论


+1表示明确的规范。我知道这是一个有2年历史的话题,但是我必须强调,您的答案是唯一指出错误的说法,即错误等同于编程失败是不正确的。

–布兰登
13年4月8日在19:54

#18 楼

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

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

#19 楼

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

我的意思是,您的老板有可能听说过“零缺陷方法”(请参阅​​第5节),而没有理会这意味着什么?
,对于管理层推迟新功能的开发是不方便的,因为您不应该放入错误。...当然,这威胁了他的奖金,因此您当然不会获得一个,因为“优秀的程序员不会“没有bug” ...

制作bug很好,只要您能找到并修复它们(当然是在合理的范围内)。

#20 楼

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

您的老板似乎是“不愿意”的人之一了解编程有什么困难,因为它只需键入“

#21 楼

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

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

除非您正在开发的东西比简单的计算器还要复杂,这是不可能避免所有错误的。甚至地狱NASA的车辆和错误都有冗余。尽管他们进行了大量严格的测试,以避免灾难性的故障。但是尽管如此,即使他们的软件中存在错误。

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

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

#22 楼

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

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

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

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

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

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

#23 楼

恕我直言的错误和突然的,错误的算法工件必须在编码过程中出现:它们会激发并迫使代码进化。
但是,有可能(通常在进行一些测试之后)检查声明之前可能使用的每个变量,以处理每个变量。可能出现的错误-使程序零错误...直到收到在讨论程序体系结构时认为不可能的功能请求;)

评论


我不知道-这听起来像是一种神秘的编程方法,这显然是一项非神秘的工作领域。您无法通过反复试验或使用占卜棒来有效编程。您是故意设计的。而且错误仍然会出现。因此,您可以修复它们。但是首先,您首先要有意地设计代码,使其不包含错误。

– Craig
2014年11月23日在22:23

#24 楼

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

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

一种判断是否存在疏忽或问题的方法设计时可能要考虑需要花费多少精力来修复错误。如果修补程序往往比较庞大,或者您认为您不太了解它们,那么就可以将代码指向可以改进的代码设计。

我认为这可以归结为一种好的方法尝一尝代码,您可以通过实践和审阅来开发代码,并阅读有类似问题的人员。

最终,完全没有错误是徒劳的,但是尝试减少您的代码却没有任何害处错误计数,除非您已经处于较低水平,否则就需要在您的时间和发现未发现的错误的时间之间进行权衡。

#25 楼

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

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

您需要的是:超高的代码质量和接近100%的测试覆盖率(单元测试+验收测试+集成测试)。

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

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

#26 楼

程序员的解决方案:


停止编程。
建造一台机械计算机。
每5年更换一次,以免机械磨损发生。手动执行所有操作。
总是让第二个人仔细检查结果。


#27 楼

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

#28 楼

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