概念 -- 浅谈前端工程化、组件化、模块化

我们发现前端工程化、组件化、模块化几乎成了每一个招聘需求或者面试问题中的必须选项,那么如何简单的来将这几个概念区分明确呢,我这里进行一个简单的解释:

首先,作者并不是一个科班出身的程序猿,作者是建筑工程程序猿,是的,没错,作者以前是搬砖的…

那我就非常非常容易的将这几个概念与实际的建筑工程做了一个对比,发现异常契合!!!接下来就是整体

工程化:

1. 往大了看: 我们一个项目,从一个需求到最终实现,有着很多很多的事情需要我们做,粗略的诸如需求讨论、设计、修改、开发、测试、上线等等一系列的步骤,整个这一个大的周期我们可以类比成一个建筑工程的规划、勘察、设计、施工、运营这么一个生命周期。
2. 往深一点看: 我们的项目中可能会有很多的页面、复杂的逻辑、但其实又能够区分具体是为了实现某个功能, 那么我们可以类比成建筑工程的各分项工程,例如钢筋工程、混凝土工程、模板工程等等,每一项工程都需要有着自己的工序、思路、规范、技术选型等等。

不知道这样说了之后是否能够理解了,所谓工程化就是我们将前端项目,不论从整体还是从某个功能需求都看做是一项工程项目,每一个都需要我们有自己的团队人员、实现思路、规范、技术选型等等,通过这样严谨而有计划有结构的去进行项目开发,而不是一闭眼闷头写。

组件化:

在一个庞大的建筑项目之中,我们不可能一次性就全面铺开将整个项目同时开干,那样是及其不高效,而且会浪费大量的人力财力,还会造成各种人员、机械、材料冲突。所以我们会将场地划分成一个个的区域,每一块区域都能够独立的修建,这样我们就能够让每块区域的人、机械、材料在各自的区域内运行,就能够大限度的做到所有区域独立自主,互不影响。
相对应的,我们也应该将我们的项目分为一块又一块独立的组件,每一个组件有着自己的状态,值,方法等等,各个组件互不影响,独立维护,这样岂不是能避免一股脑全写一起所造成的各种状态、变量、方法的冲突?

模块化:

刚刚我们说了我们将建筑工程划分为一个个独立的区域,每一个区域独立的修建,但是我们每一个区域都会做同样的事情把,例如 都要绑钢筋,都要支模板,都要浇混凝土 那我们所有的钢筋,模板,混凝土这些是不是都需要加工,如果我们每个区域都独立的进行加工,那岂不是每个区域内都要设一个对应的加工厂?这样恐怕会把场地挤爆,也会让项目直接亏崩盘吧,所以,我们会在场地上独立划出几块区域,分别对应的统一用来加工钢筋、模板等等需要加工的材料,这样不就保证了大家都可以用到加工好的材料,而且也节约场地,节约了钱吗?
相对应的咱们项目的模块化也是一样,我们有些方法、常量、或者是某些功能对象都是在多个页面使用的,那我们也可以像工程一样,将这些多处使用的相同的方法、常量、功能对象等等分别统一的放在一个文件/模块里面,这不就能够极大的减少代码量,而且极大的提高了代码的可读性、可维护性吗?

以上便是我对这三个概念的粗浅理解,也欢迎大家讨论指正