优秀的程序员总是能优雅的组织自己的代码，编写思路清晰，组织结构划分合理，从小的功能组件，到大的模块结构，都能通过合理巧妙的搭配，化复杂为简单，并且提升游戏陪玩平台系统运行效率，提高游戏陪玩平台系统代码的可维护性。
那么如何才能降低游戏陪玩平台系统开发的复杂度呢？
细分组件
都说模块化开发，其实在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的模块划分，可以很优雅的实现游戏陪玩平台系统需要实现的业务逻辑功能。
以上就是降低游戏陪玩平台系统前端开发复杂度的方式详解，希望对大家有帮助。
本文转载自网络，转载仅为分享干货知识，如有侵权欢迎联系云豹科技进行删除处理
原文链接：https://segmentfault.com/a/1190000014677368