提到"架构"这个词，你会想到什么？
我猜你想到了：微服务、分层设计、DDD、Clean Architecture、CQRS、Event Sourcing……那些看起来很高级的图，那些写满了箭头的白板，那些在技术会议上被反复提及的模式。
我曾经也这么想。我以为"架构"就是"一开始就设计好的、完美的、能应对一切变化的蓝图"。所以我做第一个工具的时候，花了很多时间画架构图、设计数据流、考虑扩展性。然后我发现——我设计的架构，90% 的"预留扩展点"永远没有被用到，但 100% 的"维护成本"却实实在在地发生了。
做了 204 个工具之后，我对"架构"的理解彻底变了。
好的架构，都是"长"出来的
我工具站的架构演进史，就是一部"从简单到复杂再到简单"的历史。
最开始，204 个工具就是 204 个独立的 HTML 文件，每个文件里包含自己的 CSS 和 JS。结构非常简单：一个文件，打开就能用。这种"架构"在工具数量少于 20 个的时候，完美无缺。
到了 50 个工具的时候，问题出现了。我想改一下全局的导航栏，需要改 50 个文件。我想加一个统一的统计功能，需要改 50 个文件。维护成本开始急剧上升。
这时候，我才引入了"公共组件"的概念——把导航栏、Footer、工具模板抽取成独立的文件，通过 JavaScript 动态加载。这是一个"架构决策"，但它不是我"设计"出来的，而是被 50 个文件的重复修改逼出来的。
到了 150 个工具的时候，新的问题又出现了。工具之间的结构差异很大——有的工具只需要一个输入框，有的工具需要多个面板，有的工具需要实时预览。原来的"统一模板"反而成了限制。于是我又把架构改成了"每个工具独立结构，但共享公共组件和样式"。
你看，每一步架构演进，都是被需求逼出来的，不是被"最佳实践"指导出来的。我从来没有在开工前画过架构图，但我每次重构都是因为"当前的架构让我痛苦"。
三个标准：什么样的架构是好的？
做了 204 个工具后，我总结出三个判断架构好坏的标准。没有用到任何"高级"词汇，但每一个都来自真实的教训。
标准一：可修改
一个好的架构，应该让你能快速修改一个功能，而不需要"理解整个系统"。
我最早做的一个工具，因为把所有逻辑塞在一个函数里，改一个小功能就需要通读整个文件。后来我学会了"规律性拆分"——不是按照"理论上的分层"（什么 Controller、Service、Repository），而是按照"我修改时实际会一起改动的部分"来拆分。
比如，工具的"输入处理"和"输出渲染"分开。因为当我改输入逻辑时，输出渲染几乎不会受影响。这种拆分不是"理论正确"的，而是"修改习惯"驱动的。
一个可修改的架构，核心特征是：当一个需求变化的时候，你只需要改一个地方，而且你知道那一个地方在哪。
标准二：可删除
这可能是最被低估的架构能力。一个好的架构，应该让你能安全地删除一个功能，而不会破坏其他功能。
我做过一个"图片批量处理工具"，第一版做了很多功能：裁剪、旋转、滤镜、加水印、调色……后来我发现，用户实际上只用两个功能：裁剪和旋转。其他功能让代码膨胀了两倍，维护成本增加了一倍。
我想删除那些没用到的功能，但我发现它们和核心功能耦合得太紧密了——删除滤镜功能，会破坏裁剪功能，因为它们共享了同一个图片处理管线。于是我只能全部保留，然后每次改任何一个功能，都得测试所有功能。
这个教训让我明白了：架构的好坏，不取决于"能不能加新功能"，而取决于"能不能删旧功能"。能加新功能，是所有架构都能做到的。能删旧功能，只有好的架构能做到。
标准三：可理解
一个好的架构，应该让一个半年后的你自己，能在 10 分钟内理解它的结构。
我经常在半年后回来看自己写的工具，然后完全不知道当时的自己在想什么。但后来我养成了一个习惯：每个工具的文件结构都遵循一个简单的模式——"入口文件"负责组装，"核心逻辑"在一个独立的地方，"UI 交互"在另一个独立的地方。不用任何框架，不需要任何依赖图，就靠目录结构和命名约定。
这种"简单"的结构，让半年后的我能在几分钟内重新上手。而"可理解"之所以重要，是因为你维护代码的时间，永远比你写代码的时间长。
架构的最终目的
很多人把架构理解为"组织的艺术"——怎么把代码组织得井井有条，怎么把模块划分得清清楚楚。但做了 204 个工具后，我发现架构的最终目的不是"组织"，而是"降低改变的代价"。
需求会变，用户会变，你会变。你的代码必须能适应这些变化，而适应变化的成本，就是架构好坏的唯一衡量标准。
好的架构，让改变变得便宜。坏的架构，让改变变成灾难。
所以，下次你做架构设计的时候，不要问"这个架构优不优雅"，要问"这个架构改了会怎样"。
写在最后
204 个工具给了我一个宝贵的视角：你不需要在第一天就"设计"出一个完美的架构。你只需要在每一天，让代码比昨天更容易修改。慢慢的，一个好的架构就会自己长出来。它不是来自你的"设计"，而是来自你的每一次"重构"。
架构不是一次性的决策，而是一个持续的过程。而这个过程唯一需要的，就是你对"做得更好"的执着。