软件工程中的常规智慧提倡将代码分解为松散耦合的功能，类和模块等。许多书籍和博客文章讨论了各种方法，可以帮助我们实现我们代码的最佳设计。

有时，我们可能会很幸运，并找到一种与我们的业务逻辑相匹配的设计模式。但是，存在提前假设的风险，这可能会导致我们的代码与业务问题失误。

我提出了一种可能听起来违反直觉的替代方法。

首先编写 Messy 代码 - 与传统的“干净”代码不同，遵循设计模式，编程范式或任何有见识的设计方法。

我的意思是 Messy 代码在这里？

我首先将所有代码放入一个函数（或方法）中。这意味着忽略了诸如分离问题，单一责任原则甚至干燥的原则（不要重复自己）。

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

在这一点上，我从技术上准备就可以打开拉动请求，这意味着有人需要阅读我的代码并进行查看。这是我检查代码是否可读性的时候。

根据我的经验，在一个地方拥有尽可能多的上下文使代码更可读。当我具有所有代码的功能时，我需要所有的上下文来告知我的设计。如果我认为代码不可读，我将大功能分解为有意义的块。相反，从头开始弄清楚构建块将花费我更长的时间。

将所有代码都放在一个地方可以被认为是凌乱的，但是比在不匹配的设计模式中实现代码更具延展性。

与现有代码库一起工作呢？

现有代码库可能具有预定义的模式。但这并不意味着它们应该是不变的。如上所述，这些模式可能非常合适。在这种情况下，我们使用它们来告知新功能的设计。但是，如果不是这样，就没有理由我们应该坚持所有未来的代码。

如果所有未来的实施是由初始设计决策决定的，则意味着我们的软件很难更改。软件应该是“软”的，即易于更改，更改是一个健康而成功的软件项目的良好指标。

我是怎么到达这里的？

我对建筑模式和设计方法的迷恋始于我职业生涯的早期。最初，我对我的代码感到尴尬，该代码效果很好，但缺乏精心设计的系统的优雅。为了解决这个问题，我沉迷于研究设计模式，后来才意识到其中许多模式主要是针对对象的编程设计的。当我继续在Python（一种更灵活的语言）中发展我的编码技巧时，我了解了寻找Python本质的设计模式的重要性。

随着时间的流逝，我还遇到了反驳，例如湿（写两次）与干燥（不要重复自己），这扩大了我对编码的看法。

鉴于软件行业中措辞强烈的文献，很容易在完成我们的任务并忽视我们的最终目标的手段上变得过于注重。因此，我发现从第一原则的角度处理编码很有价值，将问题分解为其基本要素并从这些要素中重建解决方案。从凌乱的代码开始代表我对这种理念的个人方法，我鼓励您也找到编码的独特道路。

如果您喜欢阅读这篇文章，可以在LinkedIn上关注我。

Peter Olexa上的封面照片Unsplash