之前做内部开源的小工具，一开始为了兼容多场景堆了三层抽象，刚上线的时候写业务逻辑快了至少40%，我还得意了好久。结果上周要接个边缘场景的特殊需求，光理清楚各层的封装逻辑、兼容历史调用就花了快4天，工作量是直接写原生逻辑的三倍。
这就像debug的时候碰到套了七八层的封装函数，跳来跳去半天找不到实际执行的代码。很多开源项目新手上来就喜欢搞“完美抽象”，其实完全没必要，大部分场景下够用的简单设计反而比过度抽象的“完美架构”维护成本低得多。
我整理了最近踩的12个抽象过度坑点…，要的留邮箱。

我前几年还在写代码的时候，组里有个技术迷非要给内部用的小工具堆五层抽象，说以后能适配全公司所有业务线，结果上线俩月就碰到个特殊需求，全组连加三天班才改完，最后算下来比当初直接写三个独立版本还费时间。我还听说去年有个创业公司核心项目就是因为过度抽象改不动，最后直接砍了半条业务线，不知道真假啊。对了那个12个坑点的整理能不能发我一份？我私你邮箱。