优秀的程序员总能优雅的组织自己的代码，思路清晰，组织结构划分合理。从小的功能组件到大的模块结构，都可以通过合理的巧妙搭配，既能简化复杂性，又能提高代码运行的效率和代码的可维护性。作为前端开发者，我们都应该具备这样的能力。那么如何才能降低业务开发的复杂度呢？细分的组件都讲模块化开发。其实在AMD和CMD之前就已经有了模块化开发的标准。这都是“功能开发”，一切都是功能。之前没有模块化加载的想法，毕竟没有必要。富客户端仍然是闪存的世界。基本上就是一个简单的网页嵌套了一些后端代码逻辑，然后通过后端渲染引擎渲染或者通过解释器解释产生html页面，什么ASP，PHP，JSP等等。但是，前面的模块化不是模块，为什么呢？因为没有模块加载器，加载主要由JS加载顺序控制，依赖的JS文件放在前面。模块主要是按照文件来划分的。每个文件都是一个独立的功能模块。它将需要暴露的函数挂在自定义命名空间下，调用其他函数即可。当然也有一些打包工具可以根据预先定义的文件列表将多个文件打包成一个bundle。而现在，且不说你是喜欢自己写还是使用已有的模块加载器，或者直接使用现成的脚手架如Angular、React、Vue等进行开发，当然自带模块加载，withWebpack、Rollup等打包工具可以完美构建你要添加的项目。所以建议按照功能和业务结构来划分你的组件。这样，一方面可以实现功能解耦，另一方面方便实现各自的业务逻辑，满足简洁的原则，自建模块。如果组件细分得当，就不会有一大堆功能代码，来回修改各种状态，一堆变量，一个功能写几十行。建议：ES6模块+函数式编程+webpack/rollup绝对可以满足你的需求。业务如何拆分，拆分的维度后面会介绍。什么是独立状态维护状态？状态就是数据。程序是什么？一个程序就是数据+代码。因此，数据的重要性可见一斑，如何维护数据的一份副本非常重要。那么我们前面讲了细分组件，那么数据呢？数据跟着组件，数据自然要分块。这是关于独立的状态维护。假设一个组件的代码是这样的。/**约定规范**///状态conststate={}//行为constactions={init:()=>{//组织语句循环}}//视图constview=()=>(
)将程序代码清晰地划分为状态、逻辑和视图。逻辑运行状态，查看更新显示状态。为什么说独立状态维护呢？也是为了减少耦合，提高组件重用。组件的状态应该只包含组件需要的数据，不应该包含其他冗余数据。根据软件设计中的单一职责原则，组件的职责也应该是单一的，负责这个组件的增删改查。需要注意的是，组件的开发也要遵循数据驱动的开发模式，避免直接操作DOM，即使是从DOM中获取数据，也有同学喜欢这样做，把数据挂在节点上通过data-x属性，然后通过节点获取数据。这个操作不好。首先，这个操作是有副作用的，容易产生bug，也可能存在安全隐患。细心的同学可能会问，组件通信呢？组件之间的交互可以通过注册函数钩子的方式来完成。目前也可以做一个事件注册分发的功能，但是一般一个SPA页面不需要做的那么复杂。如果真的是一个非常复杂的页面，建议做成一个页面。没有必要做一个大的SPA。关于fp函数式编程的函数式编程github地址：https://github.com/chalecao/fp这里不讨论函数式编程和OOP编程的优劣，可以两者都用，也可以用其中之一，没有限制，这取决于个人喜好。就个人而言，我曾经混合类并扩展到高级。后来逐渐转向fp函数式编程，可以完全避免使用new和this，结合上面独立状态维护中的结构划分和ES6模块划分，可以优雅的实现我需要实现Function的所有业务逻辑。