先从编写混乱的代码开始。

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

软件工程领域的传统观点提倡将代码分解为松耦合的函数、类和模块等等。许多书籍和博客文章探讨了各种方法，帮助我们实现最佳的代码设计。

有时，我们或许能幸运地找到一种与业务逻辑完美契合的设计模式。然而，过早做出假设也存在风险，这可能导致我们的代码与业务问题脱节。

我提出一种可能听起来有悖常理的替代方法。

首先编写混乱的代码——这种混乱的代码与传统的“整洁”代码不同，它不遵循设计模式、编程范式或任何带有偏见的设计方法。

我这里说的“混乱的代码”是什么意思？

我首先将所有代码放在一个函数（或方法）中。这意味着忽略了诸如关注点分离、单一职责原则，甚至是 DRY（不要重复自己）原则。

然后，我编写测试来验证我的代码是否有效。

至此，理论上我已经准备好提交 Pull Request 了，这意味着需要有人阅读并审查我的代码。这时我会检查代码的可读性。

根据我的经验，将所有上下文信息集中在一处可以提高代码的可读性。当所有代码都包含在一个函数中时，我就拥有了设计所需的所有上下文信息。如果我感觉代码难以阅读，我会将这个大型函数拆分成有意义的代码块。相反，从头开始构建这些代码块会花费我更多的时间。

将所有代码放在一个地方可能会显得杂乱，但它比使用不匹配的设计模式实现代码要灵活得多。

如果使用现有的代码库呢？

现有的代码库可能包含预定义的模式。但这并不意味着它们应该一成不变。如上所述，这些模式可能非常适用。在这种情况下，我们可以利用它们来指导新功能的设计。但如果它们并不适用，我们就没有理由在所有未来的代码中都墨守成规。

如果未来的所有实现都受制于最初的设计决策，那就意味着我们的软件难以修改。软件应该是“软的”，即易于修改，而可修改性正是衡量软件项目是否健康成功的一个重要指标。

我是怎么来到这里的？

我对架构模式和设计方法论的迷恋始于职业生涯早期。起初，我对自己写的代码感到尴尬，虽然代码运行完美，却缺乏精心设计的系统的优雅。为了解决这个问题，我埋头研究设计模式，但后来才意识到，许多设计模式最初是为面向对象编程设计的。随着我不断提升Python（一种更灵活的语言）的编程技能，我逐渐认识到寻找Python原生设计模式的重要性。

随着时间的推移，我也遇到了诸如 WET（把所有东西都写两遍）与 DRY（不要重复自己）之类的反驳论点，这拓宽了我对编程的理解。

鉴于软件行业充斥着大量措辞强烈的文献，我们很容易过于关注完成任务的方法，而忽略了最终目标。因此，我认为从第一性原理的角度来编写代码非常有价值——将问题分解成基本要素，然后基于这些要素重建解决方案。从混乱的代码开始是我个人践行这一理念的方式，我也鼓励大家找到自己独特的编程之路。

如果你喜欢这篇文章，可以在领英上关注我，获取更多内容。

封面照片由Peter Olexa拍摄，来自Unsplash