#1 楼
代码可能不正确。但是没关系。
在以下情况下，快速又脏的方法可能是正确的选择：
代码寿命短。例如，您正在使用临时程序将一堆数据转换为标准格式。
故障的负面影响很低：
重新转换是非关键性的，并且可以很容易地纠正其中的错误
最终用户是一个有同情心的程序员，他将推理错误消息并通过例如大量输入来解决它们。
有时，代码的健壮性和处理所有可能的输入并不重要。有时它只需要处理您手头上的已知数据即可。否则，快速又肮脏的代码完成工作。不会触发的错误无关紧要。即时修复或解决的错误无关紧要。
绝对至关重要的是，您不要误诊这些情况。如果您因为只使用一次代码而快速而肮脏地编写代码，那么有人决定在某个项目中重用该代码，该项目应该提供更好的代码，而该代码应该得到更多的关注。
评论
+1表示“失败的影响很小”。我最喜欢的数学风险计算方法是：风险=失败的实际后果x失败的可能性x失败的感知后果（以我的经验，利益相关者经常陷入的感知风险）
– Trav
2011-12-13 19:46
“这些代码的生命周期很短。例如，您正在使用临时程序将一堆数据转换为标准格式。”如果转换未正确完成，但是直到很晚才注意到数据中的差异怎么办？
–乔伊·亚当斯（Joey Adams）
2011-12-15 15:42
@Trav因此，仅需确认，如果失败的实际后果是巨大的，但是我认为失败的后果是零，那么没有任何风险吗？
–克里斯汀·斯图尔特（Christian Stewart）
2014年4月22日19:27
@ChristianStewart从纯粹的数学观点来看，您的主张是正确的。然而，在实践中，后果的感知为零不会抵消概率x实际后果的权重。感知被放入公式中以说明通常会影响缓解决策的组织恐惧。缺乏这种恐惧并不会减少实际的可能性或后果。因此，应该假设感知总是至少等于1（因为它可以放大但不会以任何方式抵消实际风险）
– Trav
2014年5月7日18:41
@Trav或者，重命名一个。就是说，应该将风险转换为可感知的风险，因为如果我们认为没有失败的后果，我们很可能也认为没有风险。
–纤巧
17年9月6日在21:35
#2 楼
他们没有。我目前正在开发一个由“快速而肮脏的”程序员创建的代码库，这些程序员将“稍后清理”。他们早已一去不复返了，代码继续存在，逐渐被遗忘。通常，牛仔编码员只是不了解他们的软件可能具有的所有潜在故障模式，也不了解他们给公司（和客户）带来的风险。评论
每当我听到“稍后清理”或“当事情变慢一点时我们就会这样做”时，我总是很想开始演唱“明天，明天，明天我会爱你。这总是一天天的ayayyyyyy”。不过那可能只是我。
– JohnFx
2011-12-13 17:59
我们许多人都处于这个不幸的位置。遗赠他人的技术债务实在令人沮丧。
– Mark Booth
2011-12-13 19:39
实际的问题是将其他程序员分类为牛仔，速写或其他职称。每个程序员都有一些故障模式，读取别人的代码非常困难，而发现自己的故障也非常困难。所有这些加在一起意味着人们在认为自己的代码很完美的同时，也很容易将其他程序员称为坏程序员。
–tp1
2011年12月14日的1:08
@ tp1：好的程序员可以编写易于阅读的代码。他们通过让其他人阅读并澄清所有不清楚的内容来做到这一点。通过实践，一读时不清楚的部分将缩小。
–kevin cline
2011-12-14 8:06
@JimThio，您是否认真地认为上面提到的任何程序员曾经故意编写不良代码？几年前，您是否曾经阅读过自己编写的代码？你觉得很好吗？很有可能，您当时已尽力而为，现在您仍然看到该代码中有很多需要改进的地方。
–彼得·托克（PéterTörök）
2011-12-14 11:34
#3 楼
好的，冒着被完全否决的风险，我将“恶魔拥护”反对的观点。代码清洁度。我建议，尽管这些事情很重要，但是如果您从不发货，那么这都不重要。任何从事此业务一段时间的人都可能会同意，无限期地使用某款软件是有可能的。永远的毁灭公爵，我的朋友们。有时候，应该具有一些不错的功能，或者如此紧急的重构工作应该被搁置，而这个事情应该称为“完成”。
我为此事与同事打过很多次。总是还有一个调整，“应该”做一些其他事情才能使其“正确”。您总是可以找到。在现实世界中的某个时候，足够好就必须足够好。没有任何现实，实际的运输软件是完美的。没有。充其量就足够了。
评论
或者，如果使用了数十年之久，它看起来可能会变得一团糟。如果不使用（根本不使用或使用了很长时间），它将没有机会积累任何残留物。
–没用
2011-12-13 18:32
“从事此业务一段时间的任何人都可能会同意，有可能无限期地摆弄某种软件。”可能，但是为什么要这样做呢？设置质量标准后，就可以对其进行设计，实施，测试，修复错误，再次进行测试，然后再不进行修改。它比破解它要花费更长的时间，但是一旦达到目标（实现并测试了所需的功能），就很明显，您不再需要摆弄代码。只是我的2美分。
–乔治
2011-12-13 19:54
+1 –在现实世界中，始终在代码质量和截止日期之间进行权衡。我宁愿有一个程序员能够快速生成合理的代码，而不是一个完美主义者，他花数月时间苦苦思考应该调用方法“序列化”还是“ writeToFile”。
–詹姆斯·安德森（James Anderson）
2011年12月14日，下午1:56
你说的。我曾在一个组织工作，在过去的一个房间里有一个团队，过去五年来一直在致力于新系统的功能需求，但从未为此编写过任何代码。许多编码员都是相同的（尤其是大三，刚从大学毕业，对代码必须漂亮并且符合特定的“标准”有很高的想法，否则很不好），除非停止，否则他们会无休止地尝试几个月前功能完善的东西（我有时仍然有这种趋势，我想我们都可以）。但最后，重要的是将其发布出去。
– jwenting
2011年12月14日在7:24
@乔治：我不同意你的“迷信”，认为高质量的工作比仅仅破解它要花费更长的时间。如果将编程等同于键入，那可能是正确的。考虑到整个软件生命周期，一切都会变得顺畅得多，因此，如果您关心质量，它会更快。
– ThomasX
2011-12-14 7:49
#4 楼
这样的程序员几乎永远不知道自己做对了，只是相信。而且这种差异可能并不容易理解。我还记得当我运行了第一个像样的单元测试套件后，在完全不同的水平上的信心和信任感。我以前从未知道过对我的代码有如此高的信心。因此，他们甚至可能一生都在以代码祈祷模式进行开发，善意地（并且无知地）认为自己在考虑环境的情况下尽了最大的努力。程序员和特殊情况下，当人们真正设法将整个问题空间牢牢掌握在一个完整的流程中时。我经历了这样的难得的时刻，当我完全知道要写什么时，代码就毫不费力地飞出了我的脑海，我可以预见所有特殊情况和边界条件，结果代码就可以了。毫无疑问，有一些天才程序员可以在这种状态下长时间或什至大部分时间停留在这种状态下，并且他们产生的是漂亮的代码，似乎毫不费力。我猜这些人可能觉得不需要编写微弱的单元测试来验证他们已经知道的内容。而且，如果您真的是个天才，那就可以了（尽管即使那样，您也不会永远都在那个项目周围，应该考虑自己的后继者……）。但是如果没有...面对现实吧，可能您不是。我自己，我知道自己不是。我经历了一些难得的时光-无数个小时的悲伤和悲伤，通常是我自己的错误造成的。最好诚实和现实。实际上，我相信最伟大的程序员会充分意识到自己的错误和过去的错误，因此他们有意识地养成了仔细检查自己的假设并编写那些小的单元测试的习惯，以保持自己的安全。 （“我不是一个优秀的程序员-只是一个有良好习惯的优秀程序员。”-肯特·贝克。）
评论
“仁慈地（并且无知地）认为他们正在考虑情况而尽力而为。”问题的完美总结。 ＃1由于限制而赶时间，并尽了最大的努力。 ＃2随之而来，并继承了混乱和新的截止日期，并且也尽力而为。一直到第20个可怜的灵魂，如果他有多年的时间来消除伤害，他将无法尽力而为。这就是为什么我实行“童子军”规则的原因：“让它比您发现的更干净”。给下一个汁液一个战斗的机会-可能是你。
–史蒂夫·杰克逊（Steve Jackson）
2011-12-13 17:41
有趣的是，自从开始对代码进行单元测试（在工作中）后，我感到相反。就像变得懒惰；没有理由真正理解您的代码，因为其他代码会为您捕获错误
–伊兹卡塔
2011-12-13 18:08
您编写单元测试的一部分是为了证明您自己的代码有效。更重要的是，您编写单元测试，以便其他开发人员可以放心地更改您的代码。
–斯蒂芬·格罗斯（Stephen Gross）
2011年12月13日在19:11
Donald Knuth：“当心上面代码中的错误；我只证明了它是正确的，没有尝试过。” haacked.com/archive/2007/11/29/…
– MarkJ
2011-12-13在20:30
@Izkata-如果您不了解自己在做什么，则单元测试可能已损坏，并验证代码是否具有与测试相同的错误。同样，即使100％的决策覆盖率和准确的单元测试，也可能（尽管不寻常）存在测试无法发现的错误。
–Steve314
2011年12月14日下午5:22
#5 楼
单元测试。这是对任何代码（是否脏污）都充满信心的唯一方法。评论
好报价，但不是甘道夫。是皮平，在为什么他，弗罗多和山姆在从霍比屯（Hobbiton）出发的最初旅程中，为什么不应该跨国前往巴克贝里费里（Buckleberry Ferry）。
–丹尼尔·罗斯曼（Daniel Roseman）
2011年12月13日在16:48
更正：“单元测试。这是在代码中具有错误安全感（是否脏）的唯一方法”。单元测试很好，但是不能保证任何事情。
–编码器
2011-12-13 19:12
当我想发现隐藏的错误时，我将应用程序展示给老板。我称它为老板测试，它是在单元测试之后进行的。他具有吸引人的磁场，可以吸引各种奇怪的错误以及宇宙射线直接进入CPU寄存器。
–史密斯先生
2011-12-13 22:46
当我们引用时，您可能还喜欢“测试表明存在错误，而不是没有错误”-Edsger Dijkstra
–提莫西·琼斯（Timothy Jones）
2011-12-14 6:28
-1测试不会证明凌乱的代码是正确的-单元测试不能证明任何事情，它们可以给您带来一定的信心，但没有什么比这更有价值的了。它们是一个很好的衡量标准，只是不要认为它们的意义远不止代码的一小部分完全按您编写的那样工作，不表示您编写正确或它将与其他任何事物正确交互。尽管它们通常是一个很好的措施，但是它们对于糟糕的代码没有帮助，实际上，通过给您更多的代码在每次重构中进行更改，实际上会使情况变得更糟。
– Bill K
2011-12-14 17:18
#6 楼
最好学会接受没有复杂复杂度的软件系统是完美的，无论完成了多少单元测试和代码调整。代码中总是会潜伏着某种程度的混乱和对意外情况的脆弱性。这并不意味着不应尝试编写出良好的代码或进行单元测试。这些当然很重要。需要寻求一个平衡点，并且这个平衡因项目而异。要开发的技能是了解特定项目需要使用什么级别的“完美”。例如，如果您要编写一个具有12个月项目时间表的电子病历应用程序，那么您将比一次性会议注册Web应用程序花费更多的时间进行测试并确保代码可维护。必须在星期五之前部署。当某些人在执行EMR应用程序时草率或注册应用程序由于程序员忙于调整代码而无法及时部署时，问题就来了。
评论
+1表示必须根据业务需求证明有关质量度量的决定。
–斯蒂芬·格罗斯（Stephen Gross）
2011-12-13 19:14
+1表示*“要发展的技能是了解特定项目需要使用什么水平的“完美”。” ...为公司认为可以接受的“调整”数量设置最低标准在质量方面冒险，然后坚持下去。
–S.Robins
2011-12-13 22:58
#7 楼
在子系统内，快速而又肮脏是完全可以的。如果您在废话和系统其余部分之间有一个定义良好的接口，并且有一组好的单元测试来验证您丑陋的快速而肮脏的代码是否正确，那么它可能会很好。 />例如，也许您有一些令人讨厌的正则表达式和字节偏移量来解析某些来自第三方的文件。并假设您有一个测试，说您从解析示例文件中得到的结果就是您所期望的。您可以清理此内容，以便...我不知道，当第三方更改文件格式时，反应会更快？只是这种情况很少发生。他们很有可能会更改为全新的API，而您将丢弃旧的解析器，并插入一个符合相同API的新解析器，瞧，您就完成了。快速而肮脏成为您的体系结构快速而肮脏的问题。您的核心域对象和接口都需要经过深思熟虑，但是系统的边缘通常很杂乱，而不必付钱给管道工。
评论
换句话说，模块可以是Q＆D，但是体系结构应该适当整洁。
– Kromster
2011-12-14 8:49
#8 楼
这是我认识的一个快速又肮脏的程序员的故事。我认识一个人，认为单元测试是浪费时间。经过多次争论，他终于写了一篇。它由一种长方法组成，其中撒了&&和||并返回一个布尔值到assertTrue。该语句跨越20行。然后，他又写了一个类，其中每个方法只有一行，而主方法有1000多个行，没有空格。那是一堵文字墙。当我查看他的代码并插入一些新行时，他问“为什么”。我说“因为可读性”。他叹了口气，删除了它们。他在顶部留言“别碰它，它起作用了！”
上次我与他交谈时，他为一家公司的网站编码。他正在尝试查找错误。他花了最后3天的时间每天进行8个小时。过了一会儿，我再次与他交谈，结果他的队友改变了文字的值，而没有在其他地方更新它。这不是一个常数。因此，他也更改了其他文字，以便修复其错误。他抱怨队友的意大利面代码。他告诉我：“哈哈，我们所有人都不知道与调试器通宵交流是什么感觉，而不是因为一个令人讨厌的错误而睡不着觉。”他认为这是程序员真正做到的，他对此感到非常满意。
另外，他认为阅读编程书籍和博客是没有用的，他说，“刚开始编程”，他做了12年，他认为自己是一个优秀的程序员。 br />
还有更多。
下次我们正在为我们的Web应用程序编写DatabaseManager类。他将所有数据库调用放入其中。这是一门神的课，对每一种可以想象的事物都有50多种方法。我建议我们将其分解为子类，因为并非每个控制器都需要了解每种数据库方法。他不同意，因为在整个数据库中只有一个类是“容易的”，并且在需要时添加新方法是“快速的”。最终，DatabaseManager具有从验证用户到对考古遗址位置进行排序的100多种公共方法。
评论
+1。由于某种原因，我喜欢阅读这些故事。他们甚至不再让我难过或生气。
–sam hocevar
2011-12-14 12:50
-1用于编写任何类型的_______Manager类。
–布赖恩·德里斯科尔（Brian Driscoll）
2011-12-14 17:04
@SamHocevar跑步，不要走，到thedailywtf.com
–莫格说要恢复莫妮卡
2014年11月21日在10:28
#9 楼
我避免上班太快的教训是，当我有六个月的时间来完成估计（被低估）一年的工作时。我决定在开始工作之前研究方法。最后，我投入了三个月的研究，并在剩下的三个月中完成了工作。通过识别通用功能并构建所需的库来满足这些要求，我们获得了巨大收获。当有可用的库例程时，我仍然看到编码人员在编写自己的代码。这些编码人员经常在以后需要解决相同问题时重写或充其量剪切并粘贴相同的代码。错误修复程序总是只能捕获一些代码副本。学校。“
评论
相当有道德的开发人员！
–斯蒂芬·格罗斯（Stephen Gross）
2011-12-13 19:17
#10 楼
在某些情况下，我想可能会有大量的回归测试可以找到“所有”错误并验证行为，从而允许使用快速而肮脏的编码技术。但是，多数情况下，这只是项目计划不当的问题，而一位经理则认为完成它比正确完成它更重要。忘了“以后清理”，这永远不会发生。在极少数情况下，程序员会忘记大多数代码，这会使工作变得比第一次正确完成工作更为昂贵。
#11 楼
该产品已发货。密码不存在。快速，肮脏和牛仔编码的后果使我痛苦不已。但是有时候，完成产品是重中之重，而不是弄清楚如何编写最佳代码。最终，如果该产品能够很好地交付并运行良好，那么用户和客户将不会知道或不在乎其中的代码有多“糟糕”，我承认有些时候我根本不关心“获得它”。是的，这是组织问题中的问题，并且“永远都不会发生”。但是，如果您碰巧是在一个管理不善且受最终期限驱动严重的组织中编写代码，那么在单个程序员级别，人们的选择就受到限制。
#12 楼
我认为，如果不易于维护，他们不能诚实地说出正确的做法。如果他们承认必须“稍后清理”，那么可能是他们没有考虑透彻。对其进行彻底的测试只能真正发现脏代码的任何问题。我个人并不打算发展“编写脏代码”的技能并对其正确性充满信心。我宁愿在第一时间编写正确的代码。
#13 楼
他们怎么知道他们做对了？测试是简单的答案。如果一个好的QA团队对他们的代码进行了彻底的测试并且通过了，那么我会说他们做对了。
编写快速而肮脏的代码不是一件容易的事。应该养成习惯，但同时有时您可能要花20分钟的时间编写可能被归类为肮脏的代码，或花4个小时重构很多代码才能正确执行。在商业世界中，有时只有20分钟才能完成工作，当您面临最后期限时，快速而肮脏的选择可能是唯一的选择。
我自己一直都在这两端，来修复肮脏的代码，并且必须编写自己的代码才能解决正在开发的系统的局限性。我想说，我对自己编写的代码充满信心，因为尽管它很脏，而且有时会受到一些黑客攻击我确实确保它已经过全面测试，并且具有很多内置的错误处理功能，因此，如果出现问题，将不会破坏系统的其余部分。
当我们看不起这些快速又肮脏的程序员时，我们确实需要记住一件事，客户通常不会等到拥有产品后才付款，如果产品已经发货并且进入UAT测试并从快速而肮脏的代码中发现错误，那么当他们拥有产品时，他们退出的可能性就大大降低他们面前几乎可以工作的产品，但是如果他们什么也没有，而你却告诉他们“你会我很快就会收到通知，我们只是在解决x”或“因为我们必须让y完美工作而被推迟了”，他们更有可能放弃并与竞争对手竞争。
该图像表明没有人应该低估快速且肮脏的代码的危险！
#14 楼
我认为您甚至都不应该开始走这条路。快速而肮脏可能会给您带来快速完成的时间优势，但最终您总是为此付出十倍的代价。评论
有时候，如果您现在不发货，您将一无所有...但是现在发货，可以让您“十折”地清理一下，然后又有一些是因为您击败了竞争对手进入市场，并得到了品牌认可至上。
–CaffGeek
2011-12-13 15:53
我不敢苟同。如果资金已经紧张，您将收入花在下一个产品上，并且会继续这样做，直到您的公司破产或足够大。在后一种情况下，最有可能的是，原始开发人员将不再在那里修复旧代码。
– Raku
2011-12-13 15:57
在市场上击败他人并不能保证公众会接受您的产品。如果产品包含太多缺陷，那么您最好希望自己有更多的现金来进行良好的营销和镜像营销，并与客户群保持良好的关系。这不是一个非此即彼的职位。关键是要平衡风险与回报，并及时发布可以提供的最高质量的产品。您的技能将由发布的产品质量来判断，有缺陷的软件可能会对您的图像造成损害，这是无法弥补的。
–S.Robins
2011-12-13 23:04
恳求让您喜欢的一切有所不同，但是历史上充满了很多例子，其中在适当的时间出现在任何想要的人面前，比成为最好的产品更重要。总是有机会成本，总是如此。
– Warren P
2011年12月20日在20:06
沃伦，基本上我就是这么说的。在我眼中，将代码恢复为可维护状态的机会成本成倍增加，延迟时间越长。如果您的公司由于销售顺利并且代码不是太脏而处于可以承受不可维护性灾难的位置，那就很好了，但是如果没有呢？
– Raku
2011-12-21 9:27
#15 楼
我认为，学会判断Q＆D代码的正确性不是值得发展的技能，因为这只是一种不好的做法。原因如下：我不认为“快速而肮脏的”和“最佳实践”完全可以并用。由于三重约束的偏差，许多编码器（包括我本人）已经编写出快速而肮脏的代码。当我不得不这样做时，通常是范围扩大和期限逼近的结果。我知道我正在检查的代码很烂，但是在给定一组输入的情况下，它吐出了适当的输出。对于我们的利益相关者而言，非常重要的是，我们准时交货。
通过查看原始的CHAOS报告，很清楚，Q＆D不是一个好主意，并且会在以后（维护或扩展期间）浪费预算。学习如何判断Q＆D代码是否正确是浪费时间。正如彼得·德鲁克（Peter Drucker）所说，“没有什么比有效地完成根本不应该做的事情有用的了。”
#16 楼
如果太脏了，我就无法判断我的新代码是否正确。对我而言，这主要意味着依靠您知道自己不应该依靠的事物，但同时您也知道可以在短期内工作。示例：假设按钮的高度为20像素而不是计算高度；硬编码IP地址而不是解析名称；依靠要排序的数组，因为您知道它是对的，即使提供该数组的方法不能保证能保证排序。
脏代码很脆弱-您可以对其进行测试并知道它现在可以使用了，但是可以肯定的是，它会在将来的某个时候中断（否则会迫使每个人都走在蛋壳上，以免遭到破坏）。
#17 楼
冒着引起争议的风险，我认为没有人真正知道他们的代码是100％正确，而100％没有错误。即使您的测试覆盖面非常好，并且严格遵循良好的BDD / TDD惯例，您仍然可以开发包含错误的代码，是的甚至可以包含副作用！只需编写代码并假设它起作用了，就意味着开发人员对该开发人员自身能力的过度自信，并且当出现问题（他们不可避免地会出现问题）时，调试和维护代码的工作将是昂贵的，特别是如果另一个开发人员需要维护代码稍后的。真正的不同是通过应用良好的软件工程实践来进行的，这些实践可以确保您可以真正确信自己的代码在大多数时间都可以正常工作，并且如果确实遇到错误，则更容易调试
突出的一点是，经过充分分解和测试的代码将使其他人对您的代码充满信心，在大多数情况下比您自己的信心更重要。
#18 楼
如果对脏代码进行了良好的测试，则可以信任它。问题是，对脏代码进行单元测试通常非常困难且麻烦。这就是为什么TDD这么好的原因。它揭示并去除污垢和气味。同样，单元测试通常是时间紧迫的第一件事。因此，如果最干净的人做了他曾经做过的最干净的代码，如果他由于时间紧迫而省略了单元测试，我仍然一点也不相信它。#19 楼
优秀的程序员（Quick＆Dirty以及其他）没有傲慢的态度以为自己做对了。他们假设所有大型系统都存在错误和缺陷，但是在某个时候可能已经过充分的测试和审查，以使代码可以交付的风险足够低或故障成本也足够低。因此为什么这些所谓的“快速与肮脏”程序员存在？我的假设是达尔文选择。快速发布可行代码的程序员，偶尔在竞赛发布之前交付，或者预算用尽，或者公司破产。因此，他们的公司仍在聘请新程序员来开展业务，他们抱怨必须清理的混乱情况。所谓的“纯净代码”也可以提供，但差异性不足以驱使Quick＆Dirty编码器消失。
评论
这是真的。由于Quick＆Dirty代码，疣和其他所有原因，我已经看到至少有一款产品可以发货。碰巧的是，前几天和前一个月的对比意味着比赛增加了两个月。该产品继续获得成功，Quick＆Dirty代码最终被更好的代码取代。从那时起，我不仅试图从工程的角度而且从业务/竞争的角度来查看代码质量，都试图做得更好。注意：所述代码的界面很好，只是实现的草图。
– J Trana
15年1月8日在6:04
#20 楼
可能有人会认为，代码的非最佳部分可能没有什么用，因为生存期短，对业务的影响很小或没有时间完成代码。正确的答案是您真的不知道。每次我听到有人说“这是一个小功能”，或者“让它尽可能地快速和简单”，并花足够的时间思考正确的设计时，实际上只有两件事会发生是：1-）项目变得更大，团队动力更低，正在研究充满“针迹”的代码。在这种情况下，该项目可能会很快陷入混乱。与新解决方案一样昂贵的重构。
尽量尝试最好的代码。如果您没有足够的时间，请解释为什么您需要更多时间。不要因做得不好而冒风险。永远是一个更好的专业人士。如果您是理性的，没有人可以为此惩罚您。如果他们这样做了，那不是您应该在这里工作的地方。
#21 楼
与上级讨论并评估失败的影响（如果有）。例如，您需要花1天时间来解决问题，而健壮的代码需要进行设计和体系结构更改，这可能需要4到6个月的时间+额外的验证时间才能完全验证所有受设计更改影响的工作流程。我们还必须根据列表中的时间+容量+优先级做出决定。在团队中与高层或具有较高经验的人进行良好的讨论可以帮助做出最适合团队及其交付成果的决定。
干净代码是最重要的方法，它可以作为脏代码来保存升级，客户可以通过/不通过的决策，显示制止因素，危及组织的声誉，还有更多在脏代码中使用的代码使其成为干净的代码。
评论
这似乎没有提供任何实质性的东西，超过了先前23个答案中提出和解释的要点
– gna
17年9月6日在17:35
评论
我的理论是，所有编码人员都介于“记忆者”和“理解者”之间，很少有人能做到这两者。您一次记住的废话越多，编写代码就越混乱。不管代码是否干净，使其正常工作，进行测试！但是，有些人认为为了运输软件的利益，有意偶尔检查脏代码是可以的，并计划“稍后进行清理”。嘿...地狱在“以后”之前就冻结了...
并不是所有的程序员都这么想-几个月来一直给我提供代码来维护对我来说毫无意义的代码，直到一天，就像一个电灯开关被拨动一样，因为我意识到整体的组织结构是什么，他们为什么要这样做是有道理的。我会那样做吗？不，但是有效。
@joe-+1-一些程序员太快了，无法解开那些不符合“好代码”个人想法的代码。您应该始终尝试理解代码主体及其代码样式的思想，经常会学到一些有用的信息。
快速又肮脏的程序员如何知道他们做对了？因为它有效:)