之前在 react 与 vue 之间，我总是更倾向喜欢 vue 一些。都是入侵性很强的框架， 但相对来讲，vue 显得更简单一些，起码个人感觉上比 react 更容易上手。react 里面的概念有点多，多一层抽象就多一层学习成本，如果团队的人员不是那么稳定， 可能维护性就会大打折扣。

但是最近的经历让我有些改观。

之前一直想着，要试试给前端项目写一套完整的单元测试，单纯页面的功能性测试， 已经用 testcafe 可以解决了，虽然慢一点但是毕竟功能测试跑的频率也不高， 并不是什么大问题。而 js 代码的单元测试一直让我很头疼，一个是之前的老代码， 有些老的项目并没有使用任何模块化的机制，也没有明确的边界，基本上属于不可测的状态。 另一个就是写测试的时候，还是要写很多的 mock，有些项目文档没做好，写 mock 也是很费劲的一件事情，工作量远远超出之前的预期。

直到这几天在改一个项目的代码，前端用的是 react + redux，突然发现这样的单元测试， 简直太简单了，虽然也没留下文档，但是基本上只要过一遍 reducer，就可以开始写测试了。

这让我不得不开始思考，自己之前使用 vue 的时候，是不是犯了一个很大的错误。vue 比 react 用起来更容易上手其中一个原因是它的 props 机制，是父子组件共享的简单的引用传递， 而不像 react 那样有着严格的数据流动方向控制。在应用的数据层级非常简单的时候， vue 这样用起来无疑是方便得多，但似乎写测试的时候，就要为我之前的随意付出代价了。 引用传递，意味着每一个组件都有可能对应用的数据进行修改，对组件进行隔离、测试， 无疑要先读一遍代码，有时候，这可能会是一个苦力活（毕竟有可能又是一份陈年老码）。

redux 做得事情其实也并不复杂，只是提供一个机制，或者说约束，让所有人都在一个地方进行数据操作， 干净利落地分离了渲染与数据的逻辑。不使用 redux 的话(或类似的机制)，用这些前端渲染框架的时候， 可能很难做到如此克制。

牺牲一点自由换来的收益，比我之前想象的要多得多。可能是因为一直以来都没怎么写过前端代码的测试吧， 之前的团队也没有现在这边这么混乱，文档还算齐全，以至于没有发现这种问题。 之前写码，还是不够克制啊。

但是用 redux 有另一方面的担心，多一层抽象就多一层的学习成本，除非我能有时间把这边的项目， 全都统一起来整理一遍，不然万一那天我跑路了，留下来这些个风格各异，技术方案混杂的项目， 估计就不是找一个实习生或者后端 RD 能解决的问题了。