坑多了，想吐槽一下。

吐槽一下组件化的坑

在实施组件化架构时，常常会有两种开发模式：

1. 组件与业务功能分离。即组件的开发者与业务功能的开发者，并非是同一批人。
2. 组件与业务功能绑定。即实现组件的开发者，也是实现业务功能的人。

而组件的开发则依赖于编程经验。因此功能分离，可能会导致组件的消费者需要修改组件；功能绑定，则可能会导致组件与业务功能绑定。

于是乎，我们经常会遇到各种问题。

未复用的组件：散弹式修改

开发人员最讨厌的就是散弹式修改，即：每遇到某种变化，你都必须在许多不同的 classes 内做出许多小修改以响应之（《重构》）。

如果我们不复用组件时，就会遇到这样的坑。一一修改可能并不痛苦，痛苦的是：你可能会改漏了。因为不是所有的人，都会对代码库特别熟悉。

过度复用的组件：一波未平，一波又起

过度复用，它就是反复用模式，基本上我是最常做的和遇到的情形。但是如果大家都有封装的意识，那么这个开局还是不错的。

业务变更，会导致组件功能出现差异。起先，我们只是传入一个字段，后来我们传入了一个模型，里面有十几个字段。

我们所能做的便是，在添加新功能之前，讨论一下，判断一下。

晚于进度的组件

如果开发组件和开发业务是两批人，我们会就会遇到这个情况：被所需要的组件拉后腿。于是乎，我们采用的模式是：

定义一个组件接口契约，传入相应的参数：<component [data]="users" [type]="'detail'"></component>。

尽管采用装饰器模式，能在一定程度上缓解这个问题——开发人员不需要修改代码， 或者只需要少量的修改。但是呢，对于测试人员来说，他/她们需要重新测试一遍。

所以吧，最好还是同一批人，可能呢，大公司分工明确，难免会遇到这样的情况。

不过，要是遇到生产者修改了组件，却没有通知消费者，那就是个大坑了。

未预期的复杂组件

当我们开始一个项目的时候，按照设计文档和需求，……。评估了一下，没有出现什么复杂的功能组件：

而开发者容易遇到的一个坑是，对于某一组件如 AutoComplete，便认为它的行为和其它 AutoComponent 的组件行为是相似的，而不多加考虑。结果，随着业务的持续完善，往往就会暴雷。这个时候便需要：

1. 降低交互需求
2. 待后期完善——对，可能就是不做
3. 寻找合适的替代方案

应对这种情形，最好的方式是明确好相关的需求。

无法完成的风格指南

当我们选定了一个组件库，不可避免的会遇到这个问题：

1. 图标无法修改
2. 交互行为无法修改
3. 样式难以覆盖

与此同时，它会导致另外一个问题：

1. 过多的全局 Override
2. 修改成本过高

也因此，应对的方式有：

1. 在选型的时候，多加考虑相关的因素，选择适合的组件库。
2. 在设计的时候，结合组件库的需求，设计出适合于模式库的设计。

测试无法 100% 保障

哪怕我们有 100% 的测试覆盖率，我们也无法保障没有 bug。单元测试虽然能发现 bug，但是并不能减少 bug。

• 加入 Snapshot 测试。
• 加入 E2E 测试。

这些并不能真真正正地保证功能无误，尤其是 snapshot 测试，它只是看上去更加好看而已。

所以，如何保证组件的质量？便是我们要解决的另外一个问题。

小结

没有银弹，我就是吐槽一下。