值是您打破的规则

最近，我遇到了一场关于干净代码的对话。这是在一个工程组织试图提高其输出质量的背景下进行的。因为我是一个脾气暴躁的逆向投资者，我的第一个问题是，为什么要提高质量？在我看来，我们编写的软件应该服务于客户--无论是用户还是委托它的企业，这似乎是不言而喻的。质量软件的最终服务是什么？质量提供了什么价值，工程师或企业为什么要关心它？

这个组织并不孤单。有很多公司(和很多工程师)拼命地试图量化软件的质量指标。很多公司(每家公司？)。宣称高质量软件的价值。他们的目标是生产这种高质量的软件，并列出一系列度量标准或架构指南，开发人员可以盲目地遵循这些指南来编写“干净代码”。规则和指南，即使是善意的规则和指南，也注定要失败，因为他们试图与已经决定了软件价值的公司文化作斗争--而这正是“干净代码”的价值所在--而这正是“干净代码”所要遵循的。即使是善意的规则和指南，也注定要失败，因为它们试图与已经决定了软件价值的公司文化作斗争--而这就是“干净代码”(Clean Code)--这就是“干净代码”(Clean Code)--这就是“干净代码”(Clean Code)。

如果您写下规则并坚持要求开发人员遵守这些规则，很可能是因为您的开发人员一直在做您希望他们不会做的事情。通常，这不是因为您的开发人员不理解规则和/或不喜欢您，因为他们知道组织的价值观，而这些价值观与您的规则冲突。

编纂一系列规则(特别是如果它们目前没有得到遵守的话)，以推动您的组织迈向高质量的软件，这就是在您的公司的文化和价值观与您的软件开发实践之间挑起一场斗争--在文化和其他一切之间的斗争中：文化将获胜。每个。单人间。时间到了。

品质在旁观者的眼中。成功的代码，有价值的代码，是解决业务问题的代码。我不确定好的代码是否有一个普遍的定义--但我怀疑工程师们会少抱怨那些对他们来说容易处理的代码。(注：工程抱怨已渐近于零。)。我不确定作为一个通用的质量标准是否有用，因为不同的团队，什么是好的东西会有所不同。当然，有几样东西作为指标通常是相当可靠的，但在现实中，除了增加价值之外，没有对代码的有效商业判断，也没有办法判断某种东西在实际使用之前是否增加了价值。那些让公司一年赚1000万美元，或者实现某些关键功能的代码，显然比只能在开发人员的笔记本电脑上运行的最漂亮、最有艺术气息的架构要好得多。1个。

敏捷开发的主旨是尽快将软件提供的价值交付给用户。不受软件价值影响的编码标准的整个想法是反敏捷的，而且没有在任何情况下都有意义的代码的外部度量。

换句话说：在部署软件之前，不可能为质量软件的外观编写指导方针。

有一条军事公理--你可以口述结果，也可以口述过程，但不能两者兼而有之。现在，当你有很多人在处理一个问题，并且失败的后果很严重时，口述过程绝对是正确的。事实上，如果失败的后果大于成功的回报，你绝对应该口述过程，并针对失败进行优化。这方面的很好的例子是飞机和医药。医学上的失败意味着你的死亡，而成功意味着你治愈了一种疾病，这种疾病可能会杀死你，也可能不会杀死你。2飞机上的失败意味着你的飞机坠毁了，机上所有人都死了，而成功意味着你准时到达谢博伊根。显然，失败比成功更糟糕！

那么，为什么没有更多的公司采用敏捷呢？为什么这么多的企业都有兴趣制定一系列需要遵循的规则，以便开发人员能够开发出赚钱的好代码呢？为什么这会经常失败呢？开发人员必须遵循的一系列规则就是口述过程。它针对可能发生的故障进行了优化，列出了一系列可以防止这些故障的事情。这是敏捷开发的错误方法，它要求我们将失败视为一种学习经验，放弃对过程和规则的口述，而将重点放在结果上--关注工作软件交付的价值。

放弃对失败的恐惧的问题是，它需要大量信任我们的开发人员。它要求有一种多产的文化和组织，这种文化和组织是为成功而优化的，而不是针对失败而优化的。它需要领导层的严重弱点，以及对我们人民的信心，这可能很难实现，因为它需要对自己充满信心的最终行动。我在招聘和培训我的工程师方面做得足够好，我可以相信他们在没有我的指导下会做得很好。敏捷需要的是领导者，而不是管理者-领导的表现比管理要难得多。3个。

真正的软件质量不是一套共享的规则，而是一套共享的价值观。

如果你读到这里，很有可能你要么在想，要么在想，但是如果我不告诉我的开发人员去做任务，那么他们就不会去做，我们的软件就会变得垃圾/难以维护/无法正常工作。(注：如果我没有告诉我的开发人员去做任务，那么他们就不会这么做了，我们的软件就会变得垃圾/难以维护/无法正常工作。)的原因很可能是：你读到这一步了，你要么在想，要么在想，要么就是在想，如果我不告诉我的开发人员去做任务，那么他们就不会去做，我们的软件就会变得垃圾/难以维护/无法工作。

这就是我的建议：当我们发现自己处于第二位时，那是因为我们作为软件领导者，混淆了自己对公司价值的激励。不要惊慌-这不仅很常见，而且是健康的！我们重视高质量的软件，因为高质量的软件对业务有好处。我们希望提供您所能提供的最好的东西，如果我们能够控制我们的开发人员在每个时间点上的所作所为，那么我们就可以确保它被正确地完成。

询问指示许多进程检查点(例如，没有可为空的类型)可以防止的那种失败。事实上，大多数业务软件中的软件质量检查实际上是为了使工程经理不受执行人员遇到错误并对每个人大喊大叫的失败模式的影响，或者说，员工工程师不能什么都打。

看看开发人员有多少次违反了您深思熟虑的最佳实践和精心构建的规则。你认为他们这么做是因为他们懒惰吗？因为缺乏知识？

或者，你认为面对成文规则和他们期望提供的价值之间的冲突，他们选择了自己的价值观吗？你会在州际公路上停下来救一只搁浅的小狗吗？即使有禁止在州际公路上停车的规定？

幸运的是，有一种方法可以避免首席执行官大喊大叫--与其避免后果，不如让我们重新定义一下，成功会导致我们的高管撰写热情洋溢的绩效评估，并起诉奖金支票。让我们把它表述为，用户(尤其是首席执行官)不会抵制那些妨碍他们在网站上完成任务的错误。

我的意思是，没有缺陷可能在技术上是不可能的，而且太昂贵了，无法实现。即使是像飞机这样的东西也有缺陷(看看你的737)-我们想要的是将影响降到最低。

如果将缺陷对用户的影响降至最低是我们想要的价值，那么我们需要确保我们所认为的软件质量度量实际上朝着该价值方向工作，并且我们不想制定任何妨碍该目标和我们的开发人员的规则。

你可能无法提前想象规则会阻碍你实现这个目标，所以这样想吧：

当你打破规则时(你也会这样做)，问问自己为什么？为什么现在是打破规则的好时机？这可能是因为用户不会遇到错误&实际上您的组织并不关心这一点。那很好。我确实曾在主要目标是让用户打电话的情况下工作过。如果网站缺乏功能，如果它不会完全吓跑用户，那实际上是件好事。

你的说明值很可能也很可能不是你的实际值。我曾供职于一家大谈客户价值的公司，但归根结底，他们愿意走捷径，改变任何以前存在的指导方针，以便在明天之前将某些功能交付生产。它们的真正价值在于功能交付的速度。事实上，这正是他们应该拥有的价值，因为他们并不真正清楚客户眼中的价值是什么。交付速度是非常有价值的，特别是如果你正试图快速找到一个前进的路径或确定一个产品计划！这个例子的重点不是批评有问题的公司，而是用严厉的术语来证明：你的价值观就是你打破的规则。了解这一点并接受这一点，当你要求交付团队为了交付速度而偷工减料，或者花更多时间在一项可以发布(如果不是完全没有错误，足以避免高管大喊大叫)的功能上时，你就会避免大量的认知上的不和谐。

综上所述，虽然我不认为有任何质量软件的规则可以说是通用的，但我认为有几个质量软件的质量足够广泛地适用于有用-在某些地方，违反规则可能是有启发性的，而不是罪过。

那就是：你也应该打破这些规则！当你这样做的时候，你应该考虑你所服务的更大的价值。4.

您应该能够在10分钟内调试生产中影响用户的崩溃。这并不一定意味着您需要在10分钟内解决它，但是不熟悉特定代码(但通常熟悉代码库)的开发人员应该在正确的位置查找，并且能够在10分钟内对正在发生的事情有大致的了解。

您应该能够在1天内针对用户遇到的任何bug编写测试。您应该能够在对测试方法有最少了解的情况下编写此测试。这就是为什么开发人员首先编写测试非常重要的原因--内部化并相信如果你不能写测试，那么你对它的理解就不足以写出这个特性。

要打破的规则：在编写要素之前为每个要素编写测试。

在冶金学中，延展性是指金属弯曲而不断裂的能力。您的代码应该具有此属性。熟悉生态系统但不熟悉被测系统的开发人员应该能够在2天内修复在生产代码中发现的错误。需要超过2天来修复的错误是技术债务的指标-在这个地方，您为了其他一些价值而扭曲了规则。你这么做的原因是什么？这一价值观在这里仍然适用，还是我们的价值观发生了冲突？

在其军事起源的背景下，这意味着你不会去冲刺的地方，相反，你会像汤姆·克兰西(Tom Clancy)电影中那样做糟糕的特种作战人员的行走。如果你想用不那么激烈的方式：慢而稳才能胜出。如果你遇到颠簸，把颠簸修好，这会提高你的速度。平稳而稳定地工作，清除你在前进时需要跳过的障碍物。随着你的进步，你会发现你的开发团队有目的地朝着他们的目标稳步、可预测的方向走，而不是试图绕过障碍，做英勇但难以拉开的跑酷开发动作。延迟该功能以修复释放它的障碍。

针对失败进行优化的一件事是，规则只向后看。你会注意到，我给了很多模糊的代码属性定义，没有给出很多具体的建议，比如让你的方法长达5行，在边界上使用类型，不要在每次测试中模拟超过一件事情。这是故意的。当您针对故障进行优化时，您只能针对已知故障模式进行优化。您可以保留已知故障模式的列表，并且对于每个故障模式，您可以将修复定为您必须遵循的规则。同样，这是一个很好的解决方案，因为您对前进的道路非常清楚，并且很好地处理了灾难性的故障模式。很可能你的业务线软件没有这个，所以不要假装你有。现在，在某个时候，你会发现一堆重复的失败，你会想要针对它们进行优化，最后你会得到像EveryException这样的规则，这些规则不是用它抛出的应该触发anert的相同方法捕获的。或者使用JSON Schema来验证接收控制器第一行上的请求形状。这很好-但这些&##不是这样的。#34；或者#34；使用JSON Schema来验证接收控制器的第一行上的请求形状。"；这是可以的-但是这些&##不是这样的。"；或者#34；使用JSON Schema来验证接收控制器的第一行上的请求形状。"；这很好-但是这些&##。质量看起来是这样的。5个。

这就是规则。你会打破它们的--当你这样做的时候，问问你自己为什么要打破它们。为什么我没有为那个方法写一个测试？为什么我不能在生产中观察到这个错误？5.为什么我们只在奇数星期二出动？

这些问题的答案才是你真正看重的东西。制定新的规则来捕捉您组织的价值，当您打破这些规则时(因为您会这样做)，您将使您的工程师能够向您的组织交付真正有价值的软件。

当然，作为一个结构良好且可维护的系统，您所想的一堆计算机COMEFROM可能会更有价值，但这究竟是为什么呢？我不认为这与从一袋蛇变成一袋蛇有多大关系。很多东西都是成袋的蛇。自由使用Comefrom和有价值的软件之间的具体脱节是什么？-↩。

注意那些肯定会要了你命的东西在医疗反应上的不同。如果你有严重的心脏问题，医疗专业人员会向你的身体投掷绝对致命的电流，以使你的心脏恢复节奏。这会烧毁你的胸部，重启你的大脑，痛得要死。--↩。

如果你想造一艘船，不要鼓动人们去捡木头，给他们分配任务和工作，而是要教他们向往无尽的大海。--安托万·德·圣埃克苏佩里。

注：不能遵守规则与愿意违反规则不是一回事(尽管这可能是一回事)。当你刚开始的时候，特别是10分钟的错误规则可能是很难达到的。如果你花了20分钟才找到漏洞，你是否违反了规则，还是之前的那个人违反了规则？不要将恶意归咎于名字出现在变更日志中的无能傻瓜-相反，想想导致他们违反规则的情况，并询问他们。当不可避免地是你自己的名字出现在GIT指责中时，你可以质疑为什么你违反了规则。--↩。

所有这些例子都是我试图遵循的规则。在这些规则中，我针对自己的一系列失败进行了优化。有时我会把它们弄坏。-↩。

如果这些规则中有很多你看起来不太熟悉，那是因为它们与Accelerate的DevOps&34；最佳实践几乎完全相同。Accelerate是对高性能软件团队如何最好地为其组织增加价值的实际科学度量。你应该看看这本书。你会发现明显缺乏棒球内部的架构观点，并且是绘制一条提供软件价值之路的绝妙指南。--↩