关于“可维护性”与项目结构/组件设计的简单思考

最近接手了一个项目，代码写得一般，不过能用，但是项目结构设计就糟透了。因为耦合度太高，封装太过，导致维护性相当差，加两个新接口要同时改10个组件，真是非常痛苦。不过由此，我也对项目结构/组件的设计有了一些新的想法，所以借午休时间记录一下。

设计具体业务的组件不建议过度封装，而是把视图组件封装好，每个页面设置一个配置项，配置当前页面用到的字段，这样维护起来只需改配置项就可以；

只要你的项目改起来，让人有一种：“这个改完了，卧槽，这里也要改！那里也要改！”的感觉，那么，毫无疑问，项目结构一定是有问题的，因为一个好的项目拆分得一定很好，就是你这里复用的组件就是这里，和它联动的非常少，即使是换接口版本，字段改变也能非常快速地更新；

尽可能多的让子组件只管渲染，就是说尽量只暴漏渲染用的数据的接口，保持数据的单向流动性，或者说是一个闭环，不是说改动随时存在，在哪里改都可以；

另外，插槽之类的属性（vue中的，其他类似）也要谨慎使用，因为使用插槽的时候，比较不合理的一种使用场景就是，本来传一个完整的对象，一个完整的全量数据，却把某个属性单独暴露出来，改的时候，至少就要改两个组件了，这个我接受不了；

只暴露必要的props，不要全量传进去，在子组件里解构，比如组件只需要一个对象的id值，不要把这个对象整体传进去；

保证不同版本接口格式的一致性。比如接口v1：

error_code: 0,
error_msg: "",
data: {
  list: [{ name: 'xxx', age: 16 }],
  count: 1
}

但是第二版变成：

error_code: 0,
error_msg: "",
data: {
  data: [{ name: 'xxx', age: 16 }],
  total_count: 1
}

这样的设计个人感觉非常糟糕，因为虽然是接口升级，其他改动且不管，上面里的改动是毫无意义的，count改为total_count只会让人感觉：“欸？这个分页相关的参数怎么会出问题？”真的非常让人无语。

未完待续，中午刚吃完饭，只想到这些，晚上回去有时间加个例子之类的。。。

vanishcode / Blog