今天读到 Eltrac 的 Clean Architecture 读后感，觉得还挺有意思的，于是想插入几句自己的看法。

首先让我感觉有意思的地方是，我没有想到「软件架构」这种东西，如书中所说，真的几乎没有什么进化和改变。比如书里提到的 SOLID 原则和测试驱动的方法，就已经是 OOP 里经典到入土了的教义。

关于架构的书籍我没有读过很多，但是一个从小学开始就喜欢手搓代码为生的非科班半码农，我对架构的理解就是从一次一次「推倒重建」的血泪经历中建立起来的。在设计软件的早期作出的任何一个小小的偷懒设计，到了后期都会复利增长成巨大的屎山代码。

就拿我目前的工作来说，有一个非常底层的组件就是把一个字符串反解成一套用于初始化各个对象的配置。这套东西的设计经历过几个版本：

• 最早的时候就是把字符串传来传去，每个对象都去同一个串里找属于自己的字符，代码恶心不堪。
• 第二套方案，字符串被大致切割，预处理后派发给各个对象，再在构造函数中读取子串。但是最后每个对象都要写解析逻辑，代码重复度高，我出于厌恶又给推翻了。

最终¹的设计是一套被动声明系统：每个需要配置的类只需声明一个 Schema，不用实际负责解析字符串。接收字符串的组件负责统一采集所有的 Schema，照着里面的指示将字符串中对应部分解析出来填入对象的指定域。为了简化声明的表述，我还额外开发了一套 DSL²，甚至连「有朝一日会出现 AI」这样的可能性都考虑进去了，让 Schema 里的每一项都可以附加元数据，帮助 AI 理解配置的逻辑与可调范围。八年来已经有无数的核心业务逻辑堆砌在这个底层组件上面，目前看来这个架构仍然稳如泰山，而且居然跑赢了时代，让现在接入 AI 自动配置成为可能。这算是我感到自豪的一次架构迭代。

而在这次经验中，我学到了很多架构的技巧（比如函数式编程的思维）。其实这些技巧和理论早就都写进了教科书，普通的软件工程的学生可能都在课上听过。但是，没有撞到南墙，是不知道北边为什么才是出路的；没有见证过一种架构的崩溃，就不能深刻到另一种架构或理论为什么重要。

「失败乃成功之母」——这不是一句安慰人的鸡汤文，而是一个事实：

• 失败的经验比成功的结果要更值钱！
• 失败的经验比成功的结果要更值钱！
• 失败的经验比成功的结果要更值钱！

为什么科技界在大量裁员的同时，各个公司都在亿万美元疯抢 AI 人才？其实大家在疯抢的，除了好用的脑子之外，更重要的是「哪些道路试过行不通」的经验！道理很简单：在 AI 这个光速迭代的时代，走上一条歪路导致的时间和算力的损失都是不可估量的。

失败的经验远比成功的经验多，但是失败的记录却远比成功的记录要少。很少有人会发表「失败经验」的论文，都是悄悄把失败装在脑子的角落里，然后很可惜，大部分人就会把更值钱的这部分渐渐遗忘掉。

在「数据就是一切」的 AI 时代，「没有被充分分享的失败经验」意味着什么呢——每个人不被 AI 替代的价值之所在吧！