我来了……

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

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

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

细分组件

都说模块化开发,其实在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 ,绝对可以满足你的需要,关于业务如何拆分,拆分的维度,后面介绍。

关于MVVM前端框架,这里有个编写vm的教程,github:https://github.com/chalecao/virtualdom

独立状态维护

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

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

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

/**  约定规范 **/
// 状态
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的模块划分,可以很优雅的实现我所有需要实现的业务逻辑功能。

优雅的打包

一入node深似海,如何用的更好,用的更六六六,就靠自己积累了。这里推荐个结合区块链热点做的关于nodejs的教程,github地址:chalecao/blockchain-in-nodejs
正如第一部分所提到的细分组件,组件的划分和依赖管理,都少不了npm,然后结合webpack或者rollup的打包优势,可以做到开发更轻量的应用。

未经允许不得转载:前端学堂fed123 » 如何降低前端开发的复杂度

分享到:更多 ()