优秀的程序员总是能优雅的组织自己的代码，清晰的编写思路，合理的组织结构划分，从小的功能组件，到大的模块结构，都能通过合理的巧妙的搭配，不仅能化复杂为简单，更能提升代码运行效率，提高代码的可维护性。我们作为前端开发，都应该具有这样的能力。

那么如何才能降低业务开发的复杂度呢？

细分组件

都说模块化开发，其实在AMD，CMD这些思想规范之前就已经有模块化开发的规范了，虽然JavaScript标准从es1-es4 然后隔了n年才有了es5，在那N年基本都是‘函数式开发’，一切皆函数。之前还没有模块化加载的思想，毕竟也不需要，富客户端还是flash的天下，基本都是简单的网页嵌套一些后端的代码逻辑，然后通过后端渲染引擎渲染或者解释器解释产出html页面，什么ASP，PHP，JSP等等。

然而之前的模块化称不上是模块，为什么呢？因为没有模块加载器，主要是通过JS加载顺序来控制加载的，依赖的JS文件放在前面。模块主要是按照文件来划分，每个文件是个独立的功能模块，在自定义的命名空间下挂在需要暴露出来的函数，其他函数可以调用。当然也有一些打包工具，可以根据事先定义好的文件列表，把多个文件打包成一个bundle。

而现在，且不说你是喜欢自己编写或者用现有的模块加载器，或者直接用像Angular，React，Vue等现成的脚手架做开发，当然自带的就有了模块加载，配合Webpack、Rollup等打包工具，可以完美构建你想要的项目加购。

所以呢，建议还是要按照功能和业务结构划分你的组件，这样呢一方面可以将功能解耦，一方面方便实现各自的业务逻辑，满足keep it simple的原则，模块自制。组件细分的得当，就不会出现一大堆函数代码，来回修改各种状态，一堆变量，一个函数写几十行那样。

建议：ES6 module + 函数式编程 + webpack/rollup ，绝对可以满足你的需要，关于业务如何拆分，拆分的维度，后面介绍。

独立状态维护

状态是什么？状态是数据。

程序是什么？程序是数据+代码。

所以可见数据的重要性，如何维护好一份数据至关重要。那么前面我们说了细分组件，数据呢？ 数据是跟着组件的，那么数据自然也是需要做划分了。这里面说的是独立状态维护。假设一个组件的代码是这样的。

/**  约定规范 **/// 状态const state={}//行为const actions={    init:()=>{    //组织声明周期   }}//视图const view=()=>(    
    
)

这样很清晰的将程序代码划分成了状态、逻辑和视图。逻辑操作状态，视图更新展示状态。

为什么说要独立状态维护呢？也是为了降低耦合、提升组件复用。组件的状态应该只是包含组件需要的数据，而不应该包含其他多余的数据，按照软件设计单一职责的原则，组件的职责应该也是单一的，就是负责这个组件的增删改的功能。

需要说明的是组件的开发应该也是需要遵守数据驱动化的开发模式，避免直接操作DOM，即使是从DOM上拿数据，有同学喜欢这么干哈，把数据通过data-x属性挂在节点上，然后通过节点获取数据，这样操作是不好的，首先这种操作有副作用，而且容易引发bug，而且也可能有安全风险。

细心的同学可能要问，那么组件通信怎么办呢？组件之间的交互可以通过注册函数hook的形式进行。当前你也可以做一个事件注册和分发的功能，不过一般一个SPA页面不需要做的这么复杂，如果真的是很复杂的页面，还是建议做成做个页面。没必要做成一个大大的SPA。

函数式编程

关于fp函数式编程github地址：

这里并不是来讨论函数式编程和OOP编程的好坏，你可以二者都用，也可以用其中一种，并没有限制，看个人喜好。我个人呢之前经常都是class 还有extends混入高级的this。后来渐渐转向了fp函数式编程，完完全全可以避免使用new，避免使用this，而且结合上面 独立状态维护 中的结构划分，结合ES6的模块划分，可以很优雅的实现我所有需要实现的业务逻辑功能。