软件设计哲学 程序员的工作不是编程，而是通过抽象，来管理软件的复杂性。 如果你做到了这一点，那么编程就很容易了。  我们一直以来都用错了软件开发方法。当试图改进糟糕的代码库时，我们常常想到一些通用且技术性的解决方案： 将前端迁移到 React，将后端拆分成微服务，或者用 Rust 重写所有代码。在某些情况下，这些方法确实能带来一些好处，但它们都无法从根本上解决糟糕代码库的问题。 摘自约翰·奥斯特豪特的《软件设计哲学》： 编写软件的最大限制在于我们理解所创建系统的能力。 糟糕代码库的核心问题在于它们变得过于复杂，难以理解。Rust 或 React 都无法解决这个问题。那么，什么方法可以呢？ 让事情变得更简单 解决方案在于抽象。抽象是指隐藏不重要细节、突出重要细节的概念。请注意，这里指的是概念，而不是表达这些概念的代码。 这些概念是对实际复杂性的简化模型，因此能帮助你更轻松地理解正在使用的系统。你可以进行概括性思考，只在必要时才深入探究底层细节。 记住：抽象是思想，所以好的抽象应该改变你对部分代码库的思考方式。 如果你引入了一个抽象，但它并没有改变你的思考方式，那么你创造的就不是抽象，而是一层间接层。 设计 抽象究竟该如何设计？ 有时候，好的抽象概念会非常明显地出现在你的脑海中。它们是你业务中已经存在的概念，只需要稍加梳理，并用代码恰当地表达出来。 例如，发票、产品、客户或订阅。但请注意，当你的业务谈到客户时，他们指的不是英语词典中“客户”的定义，而是他们自己的客户，这些客户有特定的规则和结构化的互动方式。 这本身就是一种抽象！你只需要用代码表达出所有这些概念，就像你的业务用语言表达它们一样。 有些抽象概念可能比较难找，需要你发挥创造力。这类工作没有万能的灵丹妙药；你只需要找到复杂性，然后尝试各种方法来应对。 通常这类工作甚至不需要编写代码，把想法写下来就足以评估你提出的抽象概念是否有效。这听起来可能有点难，但做得越多就越容易。 我之前提到的抽象概念中存在一种模式。它们都是数据类型。如果你在寻找抽象概念，你会发现数据中蕴含着大量的抽象概念。这应该不难理解！ 数据绝不仅仅是数据。数据几乎总是有其修改规则，而这些规则往往隐藏在某种概念之中，即便它们原本并不隐藏。 重新设计 有时，找到一个好的抽象概念很困难，因为代码中已经存在很多抽象概念，但它们不再适用。 桑迪·梅茨 (Sandi Metz) 在《错误的抽象》(The Wrong Abstraction) 一文中提到了一种很好的技巧来解决这个问题： 移除一个你认为不再适用的抽象概念，然后重新引入重复的部分。如果你能发现重复的部分，找到好的抽象概念就比在糟糕的抽象代码库中寻找好的抽象概念要容易得多。 值得注意的是，你不应该因为害怕出错而不敢设计抽象概念。你肯定会出错！设计抽象概念是一项创造性的工作，而创造性的工作需要反复试验。 与其害怕出错，不如大胆地设计抽象概念，并做好准备，一旦它们弊大于利，就及时进行重构。 正如编辑是写作的重要组成部分一样，重构也是软件开发的重要组成部分，而随着时间的推移，最需要重构的往往是你使用的抽象概念。 编程 你的工作不是编程，而是通过设计、改进和重新设计抽象概念来管理复杂性。如果你做到了这一点，那么编程就很容易了。 如果你不这样做，随着时间的推移，你的代码库会变得越来越难以维护。 你将无法有效地指导新开发人员。 简单的功能会变得复杂。 复杂的功能最终将变得不可能实现。 但事情并非一定要如此，如果你已经深陷其中，那么还有出路： 找出应用程序中的复杂性，弄清楚哪些重要哪些不重要，将所有内容提炼成一个概念，然后重复这个过程。你可以一次构建一个抽象层，逐步摆脱困境。 [本文转载][1] [1]: https://codeandcake.dev/posts/2025-12-12-your-job-isnt-programming