宜居代码，拥抱实际混乱

首先，我对代码整洁原则感兴趣已经有一段时间了，我认为在开发软件时牢记这些原则非常重要。其他人应该能够轻松阅读和理解你的代码，而无需解密，你也不必费尽心思添加一个简单的功能。为此，我接受了鲍勃大叔的教诲，并努力将他的话付诸实践。直到我最后一个个人项目开始，我才开始思考，我该如何才能让代码更加整洁。代码整洁本身似乎成了某种负担，它剥夺了编写代码的乐趣，我觉得代码必须尽可能地整洁。我是不是做得太过分了？

第一个极端，囤积者

在我们的职业生涯中，我们都会遇到代码库中两种极端的整洁程度。让我们从最常见的一种——囤积者代码库开始。你知道我的意思，就是那种项目，即使只是说出它的名字，你的同事也会泪流满面。你打开一个文件，只是为了在页面上添加一个简单的输入字段，三个小时后，感觉就像被代码吞噬了一样。代码库一片混乱，类多达一千多行，在第一页修改一个属性就会导致第五、六、八页的崩溃，而你却完全不知道原因。你的功能或修复会被硬塞进代码里，也许还会被用胶带封住，只是为了让它保持原样。即使你知道你可能把代码弄得更糟了，你还是会尽快关闭文件并部署它。希望永远不再碰它。你认为这种情况是如何发生的？大多数人可能会说是懒惰。但事实并非如此，至少在大多数情况下并非如此。这种混乱是每次一个小决定造成的。你一开始有一个干净整洁的类，然后在这里添加了一个小东西。它实际上不属于这里，但这样做很容易。下一个人看到这个，又修改了另一个小东西，类中本来就有一些不属于这里的东西，现在里面又多了几样东西。你明白这是怎么回事了吗？

第二个极端，展厅

这是另一个极端，并非所有人都能像识别另一个极端那样迅速地意识到这一点，但它确实存在。我喜欢把这段代码称为“代码库展厅”。如果你深入挖掘记忆，就能找到它们，那些你不断清理、不断完善代码的项目。添加一些抽象，这里添加一个模式，那里添加一个，再添加一些层。我看到那里有重复的代码了吗？我们创建一个基类吧。这个类超过20行？必须拆分！刚开始的时候，这种感觉很棒，你可以坚持一段时间，但后来项目要换人，或者你得换个项目。你回来又想添加那个简单的输入框。知道代码本身就很干净，你打开这个类，却发现应该再深入一层，因为这实际上不是这个类的职责。在下一个项目中，你还会继续深入，越来越深，哦，一个工厂。你只需要弄清楚你应该往哪个方向走，两个小时后你就会认为你找到了。但你不能只在这里添加它，因为它会出现在几个地方，你需要进一步抽象它，结果在创建抽象时才发现，其他实现需要更多的抽象。这里发生了什么？代码太干净了，就像一个展示厅的房子，就像那些准备出售的目录中的一个。它看起来很棒，但如果你仔细观察，就会发现它并不实用。没有地方放你的外套，没有地方放你的饮料，没有地方放电视，那甚至是一张全尺寸的沙发吗？但它看起来确实很棒。这主要是由软件设计书籍、文章和博客造成的，它们向我们展示了不切实际的干净代码，并给了我们错误的目标。遵循所有规则并且完全一致和抽象的代码是无法实现的，除非那里没有人住。

两者之间是什么？宜居代码

我用储物间和展厅的类比来比喻，你会发现，真正的居住空间是宜居空间。装饰精美的房间，虽然有些凌乱。它可能不如展厅漂亮，但至少有地方放带控制台的电视，还有舒适的沙发。代码也是如此，在这两个极端之间是宜居代码。其中有一些重复的代码，有些类有点大，但它们的名称会告诉你它们的作用，而且你很容易在代码中找到它们。可能有些地方仍然很乱，但我们正在缓慢但坚定地改变这种混乱，让它变得更好。这是我们应该拥抱的代码库。这是让我们有家的感觉的代码库。这是我们喜欢在其中工作的代码库！

如何到达

虽然大多数项目更倾向于“囤积者”而非“展示厅”，但将代码库迁移到理想位置的步骤是相同的​​。请遵循以下步骤，缓慢但稳步地将您的代码库迁移到一个健康宜居的地方。

1.不要让情况变得更糟！

当你接触到糟糕的代码时，不要想着轻松的办法，让情况变得更糟。不要修复整个文件，但至少要确保它不会变得更糟。这样做可能会带来双重后果，一方面会让代码变得更混乱，另一方面，如果你更倾向于使用过于干净的代码库，就不要再往上加一层了。

2. 改进而非一致性

五本书堆成一堆，一本书放在书架上，总比六本书堆成一堆要好。每次修改代码时，有人就可以把其中一本书移到书架上。如果你等着一次性把所有书都移走，那是行不通的。这对很多人来说似乎很难，因为很多简洁的代码文章都非常重视一致性。但请记住，这些文章给你的图片是展示厅代码的图片。虽然漂亮的代码看起来像一幅画，但我们需要一些杂乱才能感觉舒服。如果你从实际的角度来看，有五个混乱的类和一个应该整洁的类，总比有六个混乱的类要好。

3. 内联所有内容

不要再把重构的故事放在那里，也不要花一周时间去修复一个文件。这样做固然很好，但它可能会带来其他麻烦。你应该把这些融入到你的日常工作中。遵循侦察规则：让代码比你发现时更整洁。

4. 保持透明

你需要能够随时与所有人沟通你正在做的事情。所以不要隐藏你正在做的事情，比如在修改文件时稍微改进一下。重构和清理应该成为你所有工作的一部分，并且要公开地分享。但是请记住，你不应该请求许可！这是你工作的一部分，但要坦诚地说明你正在做的事情。还有，不要请求原谅。再说一遍，这不是你需要许可的事情。你会犯错，会把代码弄得乱七八糟，很多时候你会过度重构。犯这些错误其实很重要，这样你就知道要注意什么，并从中吸取教训。

一切都在代码库中吗？

你可能已经猜到了答案，并非如此。软件最重要的部分不是人，也不是代码，而是系统。我的意思是，代码库和团队密不可分。如果代码库一团糟，团队也会一团糟。这意味着，对于你在编写软件时遇到的任何问题，你都可以通过两种方式来解决。你可以对团队进行修改，从而推动代码库的修改；或者，你也可以对代码库进行修改，从而推动团队的修改。例如，如果你的代码包含三种“用户登录”的实现，你可以认为这只是技术债务，但这也代表了团队内部沟通的问题。这些不同的实现方式本不应该存在。所以，你目前为止读到的所有内容，也可以通过更换团队来改变？是的！只需让团队中的每个人都意识到这个原则，并开始定期就此问题进行反思，并反馈到你的代码库中，看看会发生什么。

另一个需要考虑的重要方面是软件的本质。软件开发早已从构建产品发展到如今的成品。应用程序不断发展，我们使用持续部署，产品永无止境。软件开发应该被视为一种体验，涉及开发人员、经理、产品负责人和客户，是一项集体的创造性工作。它更像是一群剧团成员排演一出戏，然后是一群工人制造实物。虽然很多开发人员并不认为自己的工作是创造性的，但如今我们从事软件开发的方式，在创意人员协作的模式下，比在制造模式下更有意义。我们越能将软件视为代码和人员相互连接的一部分，就越能接近一个让我们乐于在其中工作的代码库。而你可以做到这一点，如果你与团队成员建立信任，如果你加强联系，代码库也会随之发展。

架构和重大重构

现在我们知道了代码应该放在哪里，代码库和团队之间的关系是什么，以及如何获得我们想要的代码库。我之前一直没提到的是很多开发者梦寐以求的解决方案——大规模重构。你发现自己日复一日地与糟糕的代码作斗争，梦想着重写。如果我们能重新构建它，我们会把它建得更好。用 Ember 编写 jQuery 项目，将单体应用重写成微服务。有时这种方法能暂时奏效，但如果不改变团队内部的习惯，混乱就会再次出现。最终，你只会得到一个错综复杂的微服务网络，就像你的单体应用中错综复杂的类定义网络一样。或者，你会走向另一个极端，对整个项目进行过度设计，造成层级结构混乱，以至于没有人能在没有完整搜救人员的情况下找到任何问题。实际上，更有效的做法是一点一点地改变它。让住在代码库里的人去做。团队应该自己去探索这些洞见，不应该有外部的架构师来告诉他们如何构建。架构师似乎一直是保持结构清晰的好方法，但正如我之前所说，住在代码库里的团队与代码库是相连的，而架构师则不然。这就像一个设计师来到你家，告诉你所有东西应该是什么样子。别误会我的意思，如果你需要帮助，你应该向那些精通架构的人寻求帮助，但绝不能反过来。

这一切从何而来

宜居代码原则并非我本人所想，也不想居功。它只是让我理清了很多思路，我真心想与世界分享，让人们思考这个问题。我第一次接触到它，是在Bob叔叔的一篇博文，名为《太干净了？》。我觉得这篇文章读起来很有意思，也很喜欢他的结论。

如果我们的代码看起来有点陈旧，我们不应该感到羞耻。另一方面，我们需要勤于清理，不要让混乱失控。

Bob叔叔的文章开篇就提到了Sarah Mei的一场名为“宜居代码”的演讲，这场演讲给了我真正的启发。你上面看到的很多内容，都是我听完她的主题演讲后对软件开发的展望。如果你有45分钟的空闲时间，一定要看看这场演讲，希望它能像我一样给你带来启发！