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