如何下降前端开发的复杂度

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

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

细分组件

都说模块化开发，其实在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=()=>(
    <div></div>
)

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

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

须要说明的是组件的开发应该也是须要遵照数据驱动化的开发模式，避免直接操做DOM，即便是从DOM上拿数据，有同窗喜欢这么干哈，把数据经过data-x属性挂在节点上，而后经过节点获取数据，这样操做是很差的，首先这种操做有反作用，并且容易引起bug，并且也可能有安全风险。

细心的同窗可能要问，那么组件通讯怎么办呢？组件之间的交互能够经过注册函数hook的形式进行。当前你也能够作一个事件注册和分发的功能，不过通常一个SPA页面不须要作的这么复杂，若是真的是很复杂的页面，仍是建议作成作个页面。不必作成一个大大的SPA。

函数式编程

关于fp函数式编程github地址：https://github.com/chalecao/fp这里并非来讨论函数式编程和OOP编程的好坏，你能够两者都用，也能够用其中一种，并无限制，看我的喜爱。我我的呢以前常常都是class 还有extends混入高级的this。后来渐渐转向了fp函数式编程，完彻底全能够避免使用new，避免使用this，并且结合上面 独立状态维护 中的结构划分，结合ES6的模块划分，能够很优雅的实现我全部须要实现的业务逻辑功能。