快速又肮脏的程序员如何知道他们做对了？

如果您问程序员为什么他们应该编写简洁的代码，那么获得的第一答案就是可维护性。尽管这是我的清单，但我的主要原因是更直接，更无私的：如果太脏，我无法确定我的新代码是否正确。我发现我已经非常专注于单个函数和代码行，以至于当我完成初稿并再次查看大图时，有时并不能很好地融合在一起。花一两个小时进行清洁重构通常会发现在草稿中很难检测到的复制/粘贴错误或边界条件。

但是，有些人认为为了运输软件的利益，有意偶尔检查脏代码是可以的，并计划“稍后对其进行清理”。当可读性不理想时，是否有某种可行的技术可以使他们对代码的正确性充满信心？这是值得尝试发展的技能吗？还是人们对代码缺乏信心会使某些人容易接受？

该代码可能不正确。

但是，这可能并不重要。

在以下情况下，快速而肮脏可能是正确的选择：

• 该代码的寿命很短。例如，您正在使用即席程序将一堆数据转换为标准格式。
• 失败的负​​面影响很小：
  • 您要转换的数据不是关键数据，可以轻松纠正其中的错误
  • 最终用户是一个富有同情心的程序员，他将推理错误消息并通过例如按摩输入来解决错误消息。

有时，代码的健壮性和处理所有可能的输入并不重要。有时，它只需要处理您现有的已知数据即可。

在这种情况下，如果单元测试可以帮助您更快地编写代码（我就是这种情况），请使用它们。否则，快速又肮脏的代码，完成工作。不会触发的错误无关紧要。即时修复或解决的错误无关紧要。

绝对至关重要的是，不要误诊这些情况。如果您因为只使用一次代码而快速而肮脏地编写代码，那么有人决定在某个项目中重用该代码，该项目应该提供更好的代码，而该代码应该得到更多的关注。

他们没有。我目前正在开发一个由“快速而肮脏的”程序员创建的代码库，这些程序员将“稍后清理”。他们早已一去不复返了，代码继续存在，逐渐被遗忘。 通常，牛仔编码员只是不了解他们的软件可能具有的所有潜在故障模式，也不了解他们给公司（和客户）带来的风险。

好吧，冒着被完全否决的风险，我将“恶魔拥护”反对的观点。

我建议我们的开发人员倾向于过度关注诸如正确实践和代码清洁度之类的事情。我建议，尽管这些事情很重要，但是如果您从不发货，那么这都不重要。

从事此业务已有一段时间的任何人都可能会同意，可以或多或少地无限期地使用某种软件。永远的毁灭公爵，我的朋友们。有时候，有一些不错的功能，或者如此紧急的重构工作应该搁置一旁，而这个事情应该称为“完成”。

我为此打了很多次同事。总是还有一个调整，“应该”做一些其他事情才能使其“正确”。您总是可以找到。在现实世界中的某个时候，足够好就必须足够好。没有任何现实，实际的运输软件是完美的。没有。充其量是足够的。

这样的程序员几乎永远不知道自己做对了，只是相信。而且差异可能不容易察觉。

我记得在学习单元测试之前我曾经编程过。我还记得当我运行了第一个像样的单元测试套件后，在完全不同的水平上的信心和信任感。我以前不知道对我的代码有如此高的信心。

对于缺乏这种经验的人，无法解释差异。因此，他们甚至可以终生以代码祈祷模式进行开发，并且（无知地）相信自己在考虑环境的情况下会尽力而为。

就是说，确实有一些优秀的程序员和例外情况，当一个人真正设法以一种完整的状态将所有问题空间都掌握在他/她的脑海中时。我经历了这样的难得的时刻，当我完全知道要写什么时，代码就毫不费力地飞了出来，我可以预见所有特殊情况和边界条件，结果代码就可以了。毫无疑问，有一些天才的程序员可以长时间处于这种状态，甚至大部分时间都可以保持这种状态，而他们所产生的却是优美的代码，似乎毫不费力。我猜这些人可能觉得不需要编写微不足道的单元测试来验证他们已经知道的内容。而且，如果您真的是个天才，那就可以了（尽管即使那样，您也不会永远都在那个项目周围，应该考虑自己的后继者……）。但是如果没有...

面对现实吧，可能您不是。我自己，我不知道。我经历了一些难得的时光-以及无数小时的悲伤和悲伤，通常是我自己的错误造成的。最好诚实和现实。实际上，我相信最伟大的程序员会充分意识到自己的错误和过去的错误，因此他们有意识地养成了仔细检查自己的假设并编写那些小的单元测试的习惯，以保持自己的安全。（“我不是一个优秀的程序员，只是一个有良好习惯的优秀程序员。” -肯特·贝克。）

单元测试。这是对任何代码（是否脏）有信心的唯一方法。

附带说明；

捷径可延误很长时间（Pippin）

学会接受一个合理的复杂性的软件系统是完美的，无论完成了多少单元测试和代码调整。代码中总是会潜伏着某种程度的混乱和对意外情况的脆弱性。这并不意味着不应尝试编写良好的代码或进行单元测试。这些当然很重要。需要寻求一个平衡点，并且这个平衡因项目而异。

要开发的技能是了解特定项目需要使用什么级别的“完美”。例如，如果您要编写一个具有12个月项目时间表的电子病历应用程序，那么您将比一次性会议注册Web应用程序花费更多的时间进行测试并确保代码可维护。必须在星期五之前部署。当有人在做EMR应用程序时马虎了，或者由于程序员太忙于调整代码而没有及时部署注册应用程序时，问题就来了。

在子系统中，快速而又肮脏是完全可以的。如果您在废话和系统其余部分之间有一个定义明确的接口，并且有一组好的单元测试来验证您丑陋的快速而肮脏的代码是否正确，那么可能会很好。

例如，也许您有一些令人讨厌的正则表达式和字节偏移量来解析来自第三方的某些文件。并假设您有一个测试，说您从解析示例文件中得到的结果就是您所期望的。您可以清理此内容，以便...我不知道，当第三方更改文件格式时，反应会更快？只是这种情况很少发生。他们更有可能会更改为全新的API，并且您将丢弃旧的解析器，并插入符合相同API的新解析器，瞧，您完成了。

快速而肮脏成为问题的地方是您的体系结构快速而肮脏。您的核心域对象和接口都需要经过深思熟虑，但是系统的边缘通常很杂乱，而不必付钱给管道工。

这是一个有关我认识的快速又肮脏的程序员的故事。

我认识一个人，认为单元测试浪费时间。经过多次争论，他终于写了一篇。它由一种长方法组成，其中撒了&&和|| 并返回一个布尔值到assertTrue。该语句跨越20行。然后，他又写了一个类，其中每个方法只有一行，而主方法有1000多个行，没有空格。那是一堵文字墙。当我查看他的代码并插入一些新行时，他问“为什么”。我说“因为可读性”。他叹了口气，删除了它们。他在顶部发表评论“别碰它，它起作用了！”

上次我与他交谈时，他为一家公司编码了一个网站。他正在尝试查找错误。在过去的3天里，他每天要花8个小时。过了一会儿，我再次与他交谈，结果他的队友改变了文字的值，而没有在其他地方更新它。这不是一个常数。因此，他也更改了其他文字，以便修复其错误。他抱怨队友的意大利面代码。他告诉我：“哈哈，我们所有人都不知道与调试器通宵交流是什么感觉，而不是因为一个令人讨厌的bug睡不着觉。”他认为这是程序员真正做到的，他对此感到非常满意。

此外，他认为阅读编程书籍和博客毫无用处。他说，“只是开始编程”。他已经做了12年了，他认为自己是一位优秀的程序员。/ facepalm

还有更多。

还有一次我们为我们的Web应用程序编写DatabaseManager类。他将所有数据库调用放入其中。这是一门神的课，对每一种可以想象的事物都有50多种方法。我建议我们将其细分为子类，因为并非每个控制器都需要了解每种数据库方法。他不同意，因为在整个数据库中只有一个类很“容易”，并且在需要时添加新方法“很快”。最后，DatabaseManager具有100多种公共方法，从认证用户到对考古现场位置进行分类。

我避免上班太快的教训是当我有六个月的时间来完成估计（被低估）一年的工作时。我决定在开始工作之前研究方法。最后，我投入了三个月的研究，并在剩下的三个月中完成了工作。

通过确定通用功能并构建所需的库来满足这些要求，我们获得了巨大收益。当有可用的库例程时，我仍然看到编码人员在编写自己的代码。这些编码人员经常在以后需要解决相同问题时重写或充其量剪切并粘贴相同的代码。错误修复程序始终只能捕获某些代码副本。

当我要求他使用库代码时，一个开发人员给出了一个有说服力的答复：“这不是作弊吗？我必须在学校编写自己的所有代码。”

在某些情况下，我想可能会有大量的回归测试可以发现“所有”错误并验证行为，从而允许使用快速而肮脏的编码技术。但是，多数情况下，这只是一个糟糕的项目计划问题，而一位经理则认为完成它比正确完成它更重要。

忘记了“稍后清理”，这永远不会发生。在极少数情况下，程序员会忘记大部分代码，这会使工作变得比第一次正确完成更为昂贵。

产品出货。

代码不存在。快速，肮脏和牛仔编码的后果使我痛苦不已。但是有时候，完成产品是重中之重，而不是弄清楚如何编写最佳代码。最终，如果该产品能够很好地交付并且运行良好，那么用户和客户将不会知道或不在乎其中的代码有多“糟糕”，我承认有些时候我根本不关心“获得它”。对”，只要我把它拿出来。

是的，这是组织问题，“永远不会发生”。但是，如果您恰巧是在一个管理不善且受最终期限驱动严重的组织中编写代码，那么在单个程序员级别，人们的选择就受到限制。

我认为他们不能诚实地说，如果它不易于维护，他们就做对了。如果他们承认必须“稍后清理”，那么可能是他们没有考虑透彻。对其进行彻底的测试只能真正发现脏代码的任何问题。

我个人并不打算发展“编写肮脏的代码”并对其正确性充满信心的技能。我宁愿在第一时间编写正确的代码。

他们怎么知道他们做对了？测试是简单的答案。

如果他们的代码已经由一支优秀的QA团队进行了彻底的测试，并且通过了，那么我会说他们做对了。

编写快速而肮脏的代码不是一种习惯，但是同时有时您可能花20分钟的时间编写可能被归类为肮脏的代码，或者花4个小时重构很多代码才能正确地做。在商业世界中，有时只需要20分钟即可完成工作，而当您面临最后期限时，快速又肮脏可能是唯一的选择。

我自己一直在这两个方面，我不得不修复肮脏的代码，并且不得不编写自己的代码，以便解决我正在开发的系统的局限性。我想说，我对我的代码充满信心写这封信是因为尽管它很脏而且有点破绽，但有时我确实确保对其进行了全面的测试，并且内置了很多错误处理功能，因此，如果出现问题，则不会破坏系统的其余部分。

当我们看不起这些快速而又肮脏的程序员时，我们确实需要记住一件事，客户通常不会等到他们拥有产品后才付款，如果产品出货并且他们进入UAT测试并从快速而肮脏的代码中发现错误，那是一个错误。当他们拥有几乎可以正常工作的产品时，他们退出的可能性就大大降低了，但是如果他们什么都没有，并且您告诉他们“我们将很快修复x，您将很快拥有它”或“因为我们不得不y表现出色”，他们更有可能放弃竞争并与竞争对手竞争。

当然，如该图所示，没有人应该低估快速和肮脏的代码的危险！

我认为您甚至不应该开始走这条路。快速而肮脏可能会给您带来快速完成的时间优势，但最终您总是为此付出十倍的代价。

我认为，学会判断Q＆D代码的正确性不是值得发展的技能，因为这只是一种不好的做法。原因如下：

我认为“快速而肮脏的”和“最佳实践”并没有在一起。由于三重约束的偏差，许多编码人员（包括我自己）已经编写出快速而肮脏的代码。当我不得不这样做时，通常是由于范围不断扩大以及期限逼近的结果。我知道我正在检查的代码很烂，但是在给定一组输入的情况下，它吐出了适当的输出。对于我们的利益相关者而言，非常重要的是，我们准时交货。

查看原始的CHAOS报告可以很清楚地知道，Q＆D不是一个好主意，并且会在以后（维护或扩展期间）浪费预算。学习如何判断Q＆D代码是否正确是浪费时间。正如彼得·德鲁克（Peter Drucker）所说，“没有什么比高效地完成根本不应该做的事情有用的了。”

如果太脏了，我就无法判断我的新代码是否正确。

“肮脏”对不同的人意味着不同的事物。对我来说，这主要意味着要依靠您知道自己不应该依靠的东西，但是您也知道可以在短期内工作。示例：假设按钮的高度为20像素而不是计算高度；硬编码IP地址而不是解析名称；依靠要排序的数组，因为您知道它是排序的，即使提供数组的方法不能保证能保证排序。

肮脏的代码很脆弱-您可以对其进行测试并知道它现在可以工作，但是可以肯定的是，它会在将来的某个时候中断（或者迫使每个人都走在蛋壳上，以免遭到破坏）。

冒着引起争议的风险，我认为没有人真正知道他们的代码是100％正确，而100％没有错误。即使您的测试覆盖面非常好，并且严格遵循良好的BDD / TDD惯例，您仍然可以开发包含错误的代码，是的甚至可以包含副作用！

仅编写代码并假定其有效就意味着开发人员对开发人员自身能力的过度自信，并且当出现问题（他们不可避免地会出现问题）时，调试和维护代码的工作将是昂贵的，尤其是如果另一个开发人员需要稍后再维护代码。真正的不同是通过应用良好的软件工程实践来进行的，这可以确保您可以真正确信自己的代码在大多数时间都可以正常工作，并且如果确实遇到错误，则更容易调试而且，无论以后使用该代码的人是谁，更改和维护的成本都大大降低。

突出的一点是，经过良好分解和测试的代码将使其他人对您的代码充满信心，在大多数情况下，这比您自己的信心更重要。

如果对脏代码进行了良好的测试，则可以信任它。问题是，对脏代码进行单元测试通常非常困难且麻烦。这就是为什么TDD这么好的原因。它揭示并去除污垢和气味。同样，单元测试通常是时间紧迫的第一件事。因此，如果最干净的人做了他曾经做过的最干净的代码，如果他由于时间确定而省略了单元测试，那么我仍然一点也不相信它。

优秀的程序员（Quick＆Dirty以及其他）没有骄傲自大地认为自己做对了。他们假设所有大型系统都存在错误和缺陷，但是在某个时候可能已经过充分的测试和审查，以使代码可以交付的风险足够低或故障成本也足够低。

那么为什么存在所谓的“快速与肮脏”程序员呢？我的假设是达尔文选择。快速发布可行代码的程序员，偶尔在竞赛发布之前交付，或者预算用尽，或者公司破产。因此，他们的公司仍在聘请新程序员来开展业务，他们抱怨必须清理的混乱情况。也可以使用所谓的“干净代码”，但差异性不足以驱使“快速与肮脏”编码器灭绝。

可能有人会认为，代码的非最佳部分可能没有什么用，因为它的生存期短，对业务的影响很小或没有时间完成。正确的答案是您真的不知道。每次我听到有人说“这是一个小功能”，或者“让它尽可能地快速和简单”，并花足够的时间思考正确的设计时，实际上只有两件事会发生是：

1-）开发更大的项目，降低团队动力，开发充满“针迹”的代码。在这种情况下，该项目可能会很快陷入混乱。

2-）众所周知该项目是非最佳解决方案，因此不鼓励使用该项目，而倾向于使用新解决方案或与新解决方案一样昂贵的重构。

始终尝试做最好的代码。如果您没有足够的时间，请说明为什么需要更多时间。不要因做得不好而冒风险。永远是一个更好的专业人士。如果您是理性的，没有人可以为此惩罚您。如果他们这样做了，那不是您应该关心的地方。

与上级讨论并评估失败的影响（如果有）。例如，您可以修复脏物的情况需要1天，而健壮的代码需要进行设计和体系结构更改，这可能需要4到6个月的时间+额外的验证时间才能完全验证受设计更改影响的所有工作流程。

我们还必须根据列表中的时间+容量+优先级做出决定。在团队中与年长者或具有较高经验的人进行良好的讨论可以帮助做出最适合团队及其交付成果的决定。

干净代码是最重要的方法，脏代码可以节省升级费用，客户可以通过/不通过的决定，显示止损，危及组织的声誉，还有更多使脏代码成为干净代码的方法。