老夫聊发少年狂，左牵黄右擎苍。几年前做项目，搭建项目框架的时候，总是有激进的选型。最新的 Vue 全家桶：路由、状态管理先来一套，下载量最高的 UI 组件来一套，接口请求缓存管理都来一套，时下最火的概念总要试试吧，来一套。
最后看着东拼西凑的架构心满意足。实际开发业务的时候就抓瞎。一来是有些新概念演进的很快，熟悉度不高，要不停的看文档去学习其最佳实践；另一方面是有些工具为了覆盖更多的用法而设计了大而全的功能，但为了平衡而牺牲了易用性，导致实际使用上学习曲线变高。
这几年随着对基础工具的熟练度提升，反而开启了一种：只要够熟练，excel 都能做动画的体验。我也理解了为什么在老程序员的故事里就连使用 vim 都能拯救世界了。不沉迷于新的工具，而是把现有的工具用到极致，反倒能四两拨千斤。
去年接手了一个项目，使用了 Vue@2 的框架，引入了 vue-class-component 这个封装库来使用 class 组件，又引入了 pug 这个模板语法解析器来简化 sfc 中的 html 标签。随着项目的代码量越来越多，这一坨东西变得难以升级。
首先是 Vue 版本升级的问题，vue-class-component 是一个语法糖，意味着它会有难以预测的未知问题，排查问题不好确定是 Vue 本身问题还是语法糖的问题还是用法问题，排查难度增加。其次是 vue-class-component 不再支持 Vue@3，如果只用选项式的方式编写组件，那么只需要很小的代价就可以完成升级，而现在所有组件都是 class 组件，这意味着项目永远失去了升级 Vue@3 的可能性。
而 pug 看上去减少了很多代码量，但是它没有相匹配的 eslint 校验，对于新手也需要小心地确认缩进，我不止一次的在把 pug 代码改为普通 html 后发现 IDE 提示我不能把 div 标签放入 tbody 标签下，这样的警告在 pug 下是没有办法检测到的，除非再引入一个第三方工具（这陷入了一种为了预防问题而引入了新的潜在问题的循环）。
这使我意识到，我们使用越多的三方框架，我们对项目的掌控力就越弱。当一些框架不再维护，或没能力提供平滑升级方案时，对架构的设计者就是噩梦。
现在，在新项目的技术选型时，我只会选择稳定的原始框架，不再使用任何基于某框架的二次封装。Vue 的原始版本、Axios、Lodash 都是我乐于接受的库和框架。我抛弃了 pug 这样的短期能节省代码量的工具，而是推行 Emmt 工具，它能基于简写来快速生成标准的 html 标签。
而在一次次做减法中，我最大的感慨就是移除了状态管理库。我为什么用状态管理库呢？是因为看上去高大上，是因为网络上的大佬都用，所以在我没能真正理解其用处时就盲目跟风。在我放弃使用状态管理库后，我发现我的项目并没有因为不用它而变得状态管理更加混乱。
当我回头分析原因时，我发现，只要是有人参与状态的定义和维护，无论如何都会向混乱发展。
使用状态管理库时，总是强调保护状态，不能直接更新状态，而是编写 Mutation 来更新状态。看上去是做了解耦，但任何人都可以编写任意 Mutation 来更新任意状态，似乎没有起到保护状态的作用，只是徒增了一层无用的抽象层。到头来要学习更多复杂的概念，编写更多多余的代码，状态依旧互相缠绕，一切都向着混乱发展。
最后我使用 Vue 的简易 store 模式来维护状态（状态管理），这么多年我都被这个"简易"所欺骗，认为它简易所以可能会做不到一些事情，但用了几年发现它能适应基本所有的场景。
我不再沉迷使用复杂的框架来帮我完成复杂的项目，而是用简单的工具并制定规范来降低项目的复杂度，避免团队成员随意的定义状态或临时保存计算状态。自此团队里的所有人都不需要学习如何编写状态管理库，他们直接从对象里读取数据和更新数据，一切都清晰和直接。新人也能在项目中快速上手项目。
我依旧喜欢使用最基础的工具，比如 Axios 或 Lodash，他们简单直接，不包含需要理解的复杂概念和抽象，是可以直接使用的小零件。
而我也更喜欢在项目中自己创造工具。第三方工具为了适应更多的场景，会添加更多的代码和设计，而修复 bug 的速度也会难以控制。而自己项目里不需要考虑过多的场景，代码也会更加简单，修复问题也会更加迅速。
以上便是我从激进到克制的架构选型的心路历程。