共计 1579 个字符，预计需要花费 4 分钟才能阅读完成。
项目结束一段时间，写个文章总结下。初入项目组，看到了 3000 行的 vue 文件，一口血差点捧出，无奈上一个程序员已经离职，留下的坑，只能自己填上了。在重构项目的过程中，也发现了一些别的问题，组内分享会做了总结分享，这次总结成文章特此记录。
用搭积木的方式构建 vue 组件，就如同搭积木一样，构建我们的项目
在项目中，对于组件的划分，我们一般会划分为业务组件和功能组件，也可以称为视图组件和容器组件。在 react 中也被称为无状态组件和 UI 组件。组件划分明确，对于代码的可维护性和阅读性有一定的便利性。划分方式如下图所示：
组件设计考量，分而治之
天下大事，分久必合，合久必分。组件亦然，由以前的写在一起，到如今的明确划分。分而治之的思想，也可以让我们更加专注于主要的功能实现，便于扩展和复用。
在组件的设计中，需要考虑以下几点：
可扩展性强
扩展性首先是我们要考虑的点，如果不能扩展，就代表着代码写死，失去了代码的灵活性
组件中方法函数的抽离，便于复用，适用程度高。
尽可能使用方法定义，避免使用 template 表达式，不便于复用
文档清楚详细
毕竟写的组件是给人用的，不完善的文档让别人如何使用，肯定不能手把手教别人怎么使用吧，所以一个组件详细的使用说明是必须的。
颗粒度合适，适度抽象
这个是一个经验的问题，如何衡量颗粒度是否合适，其实是一个度的问题，每个人有每个人的看法，但是尽量保证一个组件完成的功能是单一的，而不是多个功能的结合体。
功能尽可能单一，代码行数适中
这一点和上面颗粒度类似，以代码行数衡量也可以，一般的组件如果抽离合适的话，绝对不会超过 1000 行，如果代码太多，就说明组件划分不合理，抽离不完善，需要重新设计。
必要的时候需要 ui 的配合（设计不止于好看，更关乎好用。—乔布斯）
有的组件设计出来太丑，程序员的眼光和一个专业的设计师的眼光还是有一定差距的，所以如果可以的话可以请专业的设计师设计以下 ui 界面，在一定程度上可以吸引到别人。
组件设计参考点
组件间 props 原子化
父子组件通过 props 属性传值时，尽可能的规定数据类型并且使用原始类型的数据。尽量只使用 JavaScript 原始类型（字符串、数字、布尔值）和函数。尽量避免复杂的对象。
有以下几点注意：
- 保证组件 API 清晰直观
- 更好的理解每一个 prop 的含义和作用
- 传递过于复杂的对象使得我们不能够清楚的知道哪些属性或方法被自定义组件使用，这使得代码难以重构和维护。
- 保证组件可用（防御性编程）
示例：
巧妙利用 slot 扩展组件
用好 slot 可以设计出很多优秀的组件。
合理使用 mixin 实现复用
Mixins 封装可重用的代码，避免重复。如果多个组件共享相同功能，则可以使用 mixin。通过 mixin，可以专注于单个组件的任务和抽象的通用代码。这有助于更好地维护应用程序。
及时模块化
在决定抽离成组件之前，先问一下自己下面几个问题：
- 是否有足够的页面结构 / 逻辑来保证它？
- 代码重复（或可能重复）？
- 它会减少需要书写的模板吗？
- 性能会收到影响吗？
- 你是否会在测试代码的所有部分时遇到问题？
- 你是否有一个明确的理由？
- 这些好处是否超过了成本？
当你明确了上面几个问题后，是否抽离组件相信你已经有了明确的答案。
如何设计组件？何时抽离组件？如何抽离一个合适的组件？都是一些设计原则加上实际经验相互作用下作出的判断，理论指导，实践判断。
最后用一段鸡汤文结尾：
在一天结束时，虽然你的直接责任可能是“编写代码”，但你不应忽视你的最终目标，即建立一些东西。创建产品。为了产生一些你可以引以为豪的东西并帮助别人，即使它在技术上并不完美，永远记得找到一个平衡点。不幸的是，在一周内每天 8 小时盯着眼前的代码会使得眼界和角度变得更为“狭窄”，这个时候你需要的你是退后一步，确保你不要为了一颗树而失去整个森林。
感谢各位大佬的阅读，读完希望给点个赞再走哦，谢谢！????????????
