因为我是学前端的，所以就说说前端开发阶段的编码设计问题以及我的成长。

刚开始我写js代码，很混乱，功能和算法，数据接受和返回经常放在一起，代码复用性很差，维护性能也很差，虽然做出的工具能用，但是维护的时间成本非常大，这是我刚开始时候的前端设计能力，工具的第一个版本。

后面随着工具的使用，因为产品参数以及算法经常需要添加和修改，我看到维护难度太大，不得已开始重构迭代第二版本。当然了，也是随着的我的学习进度和能力的提升，发现第一版本的代码存在着严重的缺陷。所以决心重构代码：

首先就是每个功能进行切割分开来，让它模块化，就是事件模块化，比如下载，导出，这些功能事件里面不会写算法和数据的接受返回。就是放置封装的算法（下面会进行说明）。

其次就是收据的接受和返回单独一个js文件，赋予接收的变量通过方法封装返回，或者全局引用。

最后就是最重要的一部分，封装逻辑和算法，它贯穿前面的几部分，封装的方法根据你的需要抽象或者具体化，比如固定的公式算法，可以封装成一个需要传入与公式有关的参数的方法，内部可以返回这算法最终得到的一个或者多个结果。我是用this.属性=结果值进行的，在功能事件模块中直接new进行实例化，然后对象. 属性就可以获取封装的公式计算的结果。当然也可以根据设计直接在算出的结果集变成json对象，然后拿到渲染界面的逻辑中渲染结果输出，就实现了，一个方法，到处复用，又不用重复编写，维护时就在原始的封装方法中进行添加算法和修改，其他的引用便同步改变了。代码起码减少了一半，维护成本大大降低。用专业的术语来说，上面的封装属于工厂函数设计的一种模式。

经过上面的几个步骤，前端的设计有了一个属于我的初步框架概念，数据处理，算法逻辑处理，功能事件模块，我的开发把这几块都分别用一个js文件，这样用途分明，在维护时能够及时定位。有时候开发可能并不能完全按上述进行，但是大体的设计思想是这样的。让整个前端项目一目了然。

实际上，上面几个步骤之外应该还有一个视图模块，它专门用来集合动态的html标签代码，用来动态渲染。我的设计上，如果是重复多的那肯定单独做一个js。然后结合封装的逻辑以及算法进行引用。html需要重复书写的，我一般归类为动态，在js中写，把它当做一个变量引用，而不直接在html文件中写。

上面属于我在前端开发的一些感悟，仅代表个人观点，可能会有很多问题，欢迎大家指出，一起讨论提升，谢谢。

因为我是学前端的，所以就说说前端开发阶段的编码设计问题以及我的成长。

刚开始我写js代码，很混乱，功能和算法，数据接受和返回经常放在一起，代码复用性很差，维护性能也很差，虽然做出的工具能用，但是维护的时间成本非常大，这是我刚开始时候的前端设计能力，工具的第一个版本。

后面随着工具的使用，因为产品参数以及算法经常需要添加和修改，我看到维护难度太大，不得已开始重构迭代第二版本。当然了，也是随着的我的学习进度和能力的提升，发现第一版本的代码存在着严重的缺陷。所以决心重构代码：

首先就是每个功能进行切割分开来，让它模块化，就是事件模块化，比如下载，导出，这些功能事件里面不会写算法和数据的接受返回。就是放置封装的算法（下面会进行说明）。

其次就是收据的接受和返回单独一个js文件，赋予接收的变量通过方法封装返回，或者全局引用。

最后就是最重要的一部分，封装逻辑和算法，它贯穿前面的几部分，封装的方法根据你的需要抽象或者具体化，比如固定的公式算法，可以封装成一个需要传入与公式有关的参数的方法，内部可以返回这算法最终得到的一个或者多个结果。我是用this.属性=结果值进行的，在功能事件模块中直接new进行实例化，然后对象. 属性就可以获取封装的公式计算的结果。当然也可以根据设计直接在算出的结果集变成json对象，然后拿到渲染界面的逻辑中渲染结果输出，就实现了，一个方法，到处复用，又不用重复编写，维护时就在原始的封装方法中进行添加算法和修改，其他的引用便同步改变了。代码起码减少了一半，维护成本大大降低。用专业的术语来说，上面的封装属于工厂函数设计的一种模式。

经过上面的几个步骤，前端的设计有了一个属于我的初步框架概念，数据处理，算法逻辑处理，功能事件模块，我的开发把这几块都分别用一个js文件，这样用途分明，在维护时能够及时定位。有时候开发可能并不能完全按上述进行，但是大体的设计思想是这样的。让整个前端项目一目了然。

实际上，上面几个步骤之外应该还有一个视图模块，它专门用来集合动态的html标签代码，用来动态渲染。我的设计上，如果是重复多的那肯定单独做一个js。然后结合封装的逻辑以及算法进行引用。html需要重复书写的，我一般归类为动态，在js中写，把它当做一个变量引用，而不直接在html文件中写。

上面属于我在前端开发的一些感悟，仅代表个人观点，可能会有很多问题，欢迎大家指出，一起讨论提升，谢谢。