中小型项目前端架构.docx

中小型项目前端架构
1
一、为什么要有一个好的架构
首先明确一点， 架构 是为需求服务的。前端架构存在的目的，就我个人理解来说，有以下几点：
提高代码的可读性
一个好的架构，代码的可读性一定是很强的。
简单来说，假如有一个新人加入团队，那么他接手这个项目，一定是容易上手的，能简单轻松的了解整个前端
部分的相互关系，从而找到自己需要重点关注的点。而不是需要花很多时间去熟悉这个项目的很多细节，才能
开始上手做东西。
就文件来说，可以从文件名上，分清哪些是页面、哪些是逻辑、哪些是样式、哪些是可以复用的组件、哪些是
图标组、又有哪些是移动端或是 PC 端专享的样式 / 逻辑等。
就代码来说，包括统一的命名风格，封装在同一个文件里的代码的相关性足够强等。
提高代码的可维护性
2
一个好的架构，一定是易于维护的，例如在新增需求、更改需求、修正 bug ，都不会造成意料之外的变化，比
如说修改了一个页面组件的内容，却导致另外一个页面组件发生变化（这也太坑了）。因此，要低耦合，高内
聚，以及输入和输出是可预期的。
提高代码的可扩展性
一个好的架构，一定扩展性要强，不能写死。
需求变更太 TM 正常了，新增需求也太 TM 正常了。因此好的架构，必须要考虑到这些情况的发生，因为这些
是一定会发生的。所以，一定要避免把代码写死。
比如页面组件 A 里需要有一个日历组件，而这个日历组件引用的是别人的（比如从 github 上找的）。那么尽
量不要直接在页面组件 A 里面直接引用这个日历组件，而是将写一个日历组件 B ，在这个日历组件 B 里封装你
引用的日历组件 C，然后通过这个日历组件 B 来进行操作。
原因很简单，假如某天产品经理说，这个日历组件太丑了，我们换一个吧。如果你直接在页面组件 A 里内嵌这
个引用的日历组件 C，你很可能就要改很多代码（因为不同日历组件的使用方法和暴露的接口可能不同）。假
如你还在其他多个地方引用了这个日历组件，那就更糟糕了！每个地方都要改。
3
而若是将引用的日历组件 C 封装到自己写的日历组件 B 之中，那么你只需要改日历组件 B 里的相应代码即可，
而因为日历组件 B 暴露的接口是不变的，那么自然不用修改页面中的代码了。
附图，以日历组件为例，是否考虑到扩展性的结果
未考虑到扩展性：
4
考虑到扩展性：
便于协同
包括前端和后端的协同，前端和前端之间的协同。
具体来说