Carson Gross 在《Codin' Dirty》一文中分享了他的编码风格，这与 “Clean Code” 中推崇的编码规范形成了鲜明对比。
他认为，尽管他的代码并不是特别 “脏”，但他经常违背 “Clean Code” 的建议，采取一些被认为是 “dirty” 的实践。Gross 强调，他并不是想让大家也采用 “dirty” 的编码方式，而是想展示出使用这种方式也能编写成功的软件，并希望为软件方法论的讨论提供一些平衡的视角。
他提到了三个主要的 “dirty” 编码实践：认为有时大型函数是有益的，偏好集成测试而非单元测试，以及尽量减少类 / 接口 / 概念的数量。Gross 举了多个成功的软件项目作为实例，如 SQLite、Google Chrome 和 Redis，来证明大型函数在软件项目中是可以接受的。
他还提到了他对单元测试的看法，认为在项目早期阶段不应该过度测试，而是应该等到核心 API 和概念已经形成后，再通过集成测试来测试这些高级 API。
最后，他建议尽量减少项目中的类 / 接口 / 概念数量，以减少系统的复杂性。Gross 的文章鼓励开发者，尤其是年轻的开发者，不要被 “Clean Code” 等观点所吓倒，认为即使不遵循这些传统的编码规范，也能有一个成功的软件开发生涯。
我通常倾向于将我的功能组织成以下内容：
- 几个大的“关键”函数，模块的真正核心。我对这些函数的代码行数 (LOC) 不设限制，尽管当它们超过 200-300 LOC 时，我开始感到有点难受。
- 有相当数量的“支持”函数，通常为 10-20 行代码
- 有相当数量的“实用”函数，通常为 5-10 行代码
以 htmx
issueAjaxRequest()中的 “crux” 函数为例。该函数有近 400 行！肯定不干净！
但是，这个函数中有很多上下文需要保留，并且它列出了一系列必须以相当线性的方式进行的特定步骤。将它拆分成其他函数并不能找到任何可重用之处，而且我认为如果我这样做的话，会损害函数的清晰度（对我来说更重要的是可调试性）。
-
大型函数有时是有益的：Gross 认为大型函数在代码库中是有益的，尤其是那些包含重要业务逻辑的 “关键” 函数。他指出，大型函数可以更清晰地展示出代码的重要部分，并且可以减少总的函数数量，使得代码更易于理解和记忆。他还提到了一些成功的软件项目中存在的大型函数作为实例。
-
倒向于集成测试而非单元测试：Gross 强调集成测试的重要性，认为集成测试比单元测试更为有用，因为它们在实现变化时更加稳定，并且能够表达出更高层次的不变量。他提到，在项目早期阶段过度的单元测试可能会导致大量的测试需要随着问题空间的探索而更改，从而增加了测试套件的复杂性。
-
减少类 / 接口 / 概念的数量：Gross 建议在项目中尽量减少类 / 接口 / 概念的数量，以减少系统的复杂性。他认为，过度分解软件可能会导致系统变得过于复杂，而一个如 Active Record 这样的多功能类可以简化数据从数据库到 HTML 文档的处理流程。
更具体的内容可以查看原文：https://htmx.org/essays/codin-dirty
更多独家技术见解与热门话题讨论，尽在【开源中国 APP】，与数百万开发者一起，随时随地探索技术无限可能。
