你不相信代码整洁。

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

昨天又发生了同样的事情。

我当时正全神贯注地写代码，突然我的经理不知从哪儿冒出来，开始大吼：“圈复杂度没问题，包之间的耦合度也可接受！别再拆分那个类了！别提取新方法！看在上帝的份上，你敢再写测试试试！”

或许这件事昨天没发生，前天也没发生，在我20年的职业生涯中，任何一天都没发生过。事实上，我从未见过其他人遇到过这种情况。

其中一个原因是，没有哪个管理者知道什么是圈复杂度，他们说不出任何重构的概念，也无法区分测试代码和生产代码。他们为什么要知道呢？这根本不关他们的事。

另一个原因可能是，优秀的管理者即使了解我们的专业术语，也清楚自己的职责范围，明智地选择远离规则。这与他们无关。

即使我的几十位经理中没有一位曾明确或隐晦地禁止过任何技术实践，为什么我仍然看到了大量糟糕的代码库、漏洞百出的应用程序和难以维护的系统？

会不会是我们的错？

时间压力

当然，这从来都不是我们的错。如果我们当初有足够的时间编写简洁的代码，进行一些重构，编写更多的测试，遵循所有这些“最佳”实践……

但是，你的经理却不断要求添加更多功能，并设定一些莫名其妙的截止日期。所以我们被迫偷工减料，那么我们该选择在哪些方面做出妥协呢？

是你决定不进行清理，是你决定让每个程序独立运行，是你决定不编写任何测试。所有这些提高质量的做法都会带来额外的成本。

优质产品价格昂贵。

应用质量与代码质量

对某些人来说，质量就是价值。
杰瑞·温伯格

毋庸置疑，应用程序的质量需要时间：美观的界面、出色的用户体验、快速、流畅、可扩展、始终可用、功能齐全。 富有的没错……所有这些都会影响客户对您应用程序质量的看法。

但是代码质量如何呢？

你的代码库和系统的状态，以及你使用制表符还是空格，对你的用户来说完全无关紧要。这对他们来说没有任何价值。

代码质量是开发者在代码库中最看重的因素。

我们对代码库的所有重视属性都可以归结为一点：在不影响应用程序质量的前提下，修改代码的难易程度。

所谓易于更改，是指更改速度很快。

代码质量使我们能够更快地工作，这与我们通常认为质量昂贵的看法相悖。

为什么代码质量被认为成本高昂

代码质量之所以被认为成本高昂，是因为我们把时间投入到一些实际上并不能提高质量、也不能让我们更快的事情上。

其中一些包括：

• 优美的代码
• 设计无需改变
• 抽象
• 最佳实践

优美的代码

在我早期的软件开发生涯中，我读过很多书籍和文章，这些书和文章让我觉得软件开发就像：

图片来源：Uri Tours (uritours.com) / CC BY-SA。

这种看法，再加上即使是最简单的工作我们也被视为天才，让我们有理由像米开朗基罗那样行事：

但软件开发不是艺术，代码不需要像小说一样易读，你的代码库也不是禅意花园。

我花了太多时间在毫无意义的争论、无休止的重构和代码润色上，只为了追求代码的美观。这在精神上确实很有满足感，但对实际业务价值却微乎其微。

尽管浪漫的工艺理念非常吸引人，但我希望工艺书籍的封面能够展现出我现在最认同的那种工匠形象：

图片来源：Pintor de brocha Gordahttps://oficiossite.wordpress.com

或许没那么性感，但更符合我们实际的工作内容。

记住，对任何代码来说，最美妙的事情就是删除它。

设计无需改变

在软件开发中，变化是永恒的。

应对变化的普遍做法是在我们的设计中添加足够的钩子、扩展点和接口，这样当变化来临时，我们就不需要更改现有的代码。

我们通过设计不发生变化的方案来应对变化。

当新的需求与设计相契合，并且允许我们在不修改现有代码的情况下添加新功能，而不用担心破坏现有功能，并且只需付出最小的努力时，这该是多么美妙的事情啊！

这是开闭原则的最佳体现。

当然，这样做非常有用，如果你不尝试设计一个不会改变的系统，那简直太傻了。但是，你是如何得出这个设计的呢？

一种方法是展望未来，预测系统需要什么。除非你的预知能力特别强，否则这通常会导致过度设计。

另一种方法是争取成为“事后诸葛亮”，这样，当事情本该如何发展变得显而易见时，我们就能采取行动去实现它。

为了在不破坏现有功能的情况下实现“事后诸葛亮”式的设想，你需要做些什么？

抽象

人类天生擅长在任何地方发现模式，即使根本没有模式，编程也不例外。

当我们在代码中发现此类模式时，我们往往会强烈地想要用抽象的方式来定义它们，但这常常会导致错误的抽象。

我无法比桑迪·梅茨更好地解释错误的抽象概念代价有多么高昂：

重复劳动远比错误的抽象便宜得多
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

最糟糕的是，我们竟然觉得我们自己创造的抽象概念如此美丽。

最佳实践

作为专业人士，我们已经将我们发现的所有实践和过程都变成了教条，将一些在某些情况下有用的东西，变成了必须普遍应用的东西，忽视了我们的背景，也未能理解这种实践的背景。

正如我在《100%代码覆盖率的悲剧》一文中所说：

一旦某种“良好做法”成为主流，我们似乎就会忘记它是如何产生的，它的好处是什么，以及最重要的是，使用它的代价是什么。

相反，我们只是机械地应用它，而不去深思熟虑，这通常意味着我们最终最多只能得到平庸的结果，失去大部分好处，却付出全部（甚至更多）的成本。

我们不相信代码整洁。

因为我们内心深处仍然相信，那些所谓的好做法并不能让我们更快。它们反而会为了保证质量而放慢我们的速度。

但应用程序质量与代码质量是不同的。

代码质量并不昂贵，它是提高速度的唯一途径。

最终由你和你的团队决定遵循哪些实践，哪些实践能够提高代码和系统的质量，哪些实践能够提升速度。很抱歉，但你需要进行衡量。

请记住，保持开放的心态。代码和实践只是工具。不要以一把锤子为傲。

为你的工作感到自豪，但要记住，你的工作是以最有效率和最有效的方式解决客户的问题。