如何从零开始，形成自己的模块化思维方式？

今天这篇文章说的是模块化的思维方式，并不仅限于教你怎么写前端模块化。

计算机这东西不是凭空出现的，它是为了解决一些实际的问题，有很多时候是对现实世界的模拟。遇到问题时，经常会有人说，要有大局观，要具体问题具体分析，也可以牵强的解释为这就是模块化思维的一种，也是用来解决问题的一些思路，方法。

大局观，就是站在整个项目、应用的层面上去设计它的结构；具体问题具体分析，其实就是软件工程中的“分而治之”的思想，无论多么复杂的系统，都可以从这二个方面进行解构。

<!-- -->

那么，“我”，现在没有这种思想。现在“我”该怎么做，才能有这种思想？现在我们不提大局观，先实现一个小目录，“拆分一个小模块”。

说，“现在有一个首页的竖列的导航条，（很简单我就不上图了），就是一个ul和li的竖列导航条”。现在要把它设计成一个相对独立的模块，该怎么搞？

首先，你要分析需求点啊，

- 这个menu菜单都有哪些功能呢？

- 这些li是怎么生成呢？

- 这些li里的字是从哪来的呢？

- 当li被点击的时候，页面上的被更新的内容从哪来呢？

- 这些li里的自定义属性都有哪些呢？

- ...随需求再添加

把这些需求相关的东西都列出来，写在纸上。这是第一步。

第二步，因为这个menu菜单的需求，所以它里面必然有一些是不能变的核心的属性、方法；还有一些是可能被修改的，可能被继承添加的。就是说，可能会变的东西。

你把，哪些是不变的，哪些是会变的，把它们分别在纸上列出来。这个工作算是相对简单的UI界面需求分析和模块结构设计的阶段，

<!-- -->

接下来，咱们使用最简单的prototype原型模式，以伪代码的方式来实现一个这个模块。

上面已经把需求用中文写好啦，那我们接下来就把中文给翻译成js代码，就ok啦。

代码太长一屏截不下，用ps接了一下。这样一来，一个最简单、最好理解，同时功能还基本ok的模块，就搞出来啦。然后随着需求的不断添加，业务的不断复杂，这个模块会不断的扩大，再扩大。

这时你就需要把它拆分，再拆分，在这个过程中，你的模块化思维方式，就不断的熟练再熟练出来啦。

在这个过程中，你还可以不断的添加一些新的方式、思想在其中，如果你愿意的话。例如单例、call和apply搞搞继承，可以让你的模块更加强大。当然了，这是美好的未来，哈哈，为了实现它，首先你必须先实现我上面所展示的那个“小小的目标”。

<!-- -->

再谈点其它的啊。

组件的意义吧，在最开始的时候，是为了重复使用。早期的想法是，如果某个东西不需要在多个页面上重复使用，那么就不需要把它单独摘出来。应该说这个想法在当时是没有问题的。

但是现在是什么行情了，现在的情况是网站或是应用的复杂程度已经跟页面的数量没有关系啦。就例如我淘宝爸爸的首页，那么多功能搞三搞四的骗我老婆们的钱，但它其实只有一个页面。

这么多、复杂的需求、功能，如果不组件的话，那结果就是所有的业务代码都罗列式的堆积在前端页面上。所以现在组件化的意义，“已经从复用变成了分治”。

所以就是最好整个页面上所有的功能块、需求都给它组件化了；所以最终导致了ReactJs、VueJs的出现，也就是全面的拥抱组件化。

<!-- -->

写的顺手了就有点收不住了，再说几句。

ReactJs、VueJs这些框架，号称数据驱动视图。你也不必把句话看得多么高大尚。坦率的讲，前端开发不操作dom，那是不可能的。这句话也就是说，它把json和dom的相互映射影响，给自动化了。

也就是说，如果用了ReactJs、VueJs，那么上面那个代码里就没有createLi()之类生成dom和liEventFn()绑定事件的东西了。

所以，就有那么一种观点，“至少到目前为止，前端开发没有银弹”。

所以，ReactJs、VueJs之类的框架，在前端开发的发展过程中，依然只是过客，它们不是终点！

所以，学习前端开发的根本，依然是学习JavaScript语言本身、掌握模块化思维方式、理解业务和需求！

兴之所致，写的有点跑偏，请大家笑纳。