在软件开发中，我们常常被教导要“优化架构”、“抽象层次”、“面向未来”。于是，很多人养成了一个习惯：无论功能多简单，先搭几层抽象再说——接口、实现类、工厂、策略、服务层……文件夹层层嵌套，类名整整齐齐，仿佛代码越“架构”，就越专业。
但现实往往是：当你想看懂一行代码做了什么，却需要点开五个文件夹才能找到那一行逻辑时，这种“架构”已经变成了灾难。
认知的边界：7±2法则
心理学中有一个著名的“神奇数字7±2”：人类的工作记忆容量大约只能同时处理5到9个信息块。这意味着，当我们阅读代码时，大脑能高效处理的单层并列项通常就在这个范围内。
如果你把一个功能拆成5个平铺的步骤，我一眼就能看懂流程。但如果你把它拆成三层，每层又拆成四个组件，我就不得不在脑海中维护一个树形结构，逐层理解每个组件的职责，再拼凑出整体逻辑。每多一层，认知负担就指数级上升。
可读性的核心，是让读者尽可能少地切换上下文。 当逻辑本身只有两层（例如“输入-处理-输出”）时，强行引入第三层抽象，就像在平地上硬挖出一条沟，然后再架桥——除了增加复杂度，没有任何好处。
嵌套文件夹的陷阱
用一个形象的比喻：假设你有一篇需要保存的文本。你的第一反应不是把它放在桌面上，而是创建一连串嵌套文件夹：
文档/个人/项目/2024/技术/架构/思考/最终版/千万别改/真的最终.txt
即便每个文件夹的名字都起得恰如其分，每次想打开这篇文本，你都要点开七八层窗口。如果某一天你想把这篇文本和另一篇合并，你还得原路返回，再点开另一串文件夹。
代码中的“无脑架构”正是如此。为了所谓的“扩展性”或“职责分离”，我们把一个简单的函数拆成抽象类、具体实现、依赖注入、配置工厂……最后，核心逻辑淹没在层层包裹之中。每个类只有几行代码，但整个系统变成了一个巨大的迷宫。
命名清晰并不等于结构清晰。 即使每个文件夹都有合理的名字，多层次的嵌套依然会让人迷失方向。只有当你对未来可能插入的“文本”有十足把握——比如知道这里将来要放小说，那里要放菜谱——提前建好文件夹才有意义。否则，你只是在为自己的“猜测”买单。
什么时候该用“笨方法”？
“笨方法”听起来不高级，但它往往是最直接、最易懂的。当你的逻辑只有两层（比如一个条件分支，或者一组顺序操作）时，直接平铺就是最好的架构。比如：
def process_order(order):
validate(order)
calculate_total(order)
apply_discount(order)
save_to_db(order)
send_notification(order)
五个函数并列，一目了然。你不需要一个OrderProcessor接口、一个OrderService类、再一个OrderHandler抽象。如果未来真的需要扩展（比如支持多种订单类型），到那时再重构也完全来得及——因为那时的需求是真实的，你的设计会更有依据。
架构的核心是服务于内容，而不是服务于架构本身。 正如文件夹是为了整理文本，而不是让文本更难找。
如何判断是否过度设计？
一个简单的自测方法：如果删除某一层抽象，代码依然清晰可用，那么这一层可能就是多余的。 另一个方法是“读者测试”：假设一个不熟悉项目的同事来看这段代码，他需要花多长时间理解核心逻辑？如果大部分时间都花在跳转和猜测上，那就是警示信号。
结语
软件工程中有一条经典原则：KISS（Keep It Simple, Stupid）。 复杂的架构往往不是智慧的产物，而是对不确定性的过度防御。与其为遥远的未来搭建空中楼阁，不如让当下的代码保持简单、直接、可读。
下一次当你忍不住想新建一个文件夹、添加一个接口、引入一层抽象时，先问自己：我是在优化代码，还是在创造套娃？ 记住，最好的架构，是让读者一眼就能看到那篇“文本”，而不是先穿过一片迷宫。
