前端时间写了个自己觉得很差的代码,当然写之前我是没想到我会写的那么烂,但是写着写着,就觉得要歪楼了,写到最后,就真的觉得这代码只有我自己能看的懂~~忧伤~~这里记录总结一下
客观原因
1.操作复杂:
多级联动(最多有5层联动)且页面中有多处多级联动,接口又需要不同的参数
校验也很复杂
上传,下载,弹窗,弹窗上联动,不同条件下交互的不同,
总之很复杂的交互,但好像也想不出更优的交互,只能怪这个需求本身就很复杂吧。
2.需求不是一开始就是完善的,开发的过程中不断有调整,这会导致一些代码冗余和代码设计问题。
3.涉及的部门太多,接口太多,合作的人也很多。跨部门合作必须至少有一个人负责推动进度。
4.测试数据太少,且不稳定。依赖外部部门的数据、接口总是不稳定,且响应不及时,影响进度。(当时就只是用fiddler代理数据,挺麻烦的,还是应该研究一下mock server之类的模拟数据。)
当然罗列这些不是为了推卸责任,而是这些因素也是每个开发在项目进度、风险把控、产品设计、代码实现的过程中也必须考虑的点。
做的比较好的地方
1.公共函数,公共变量、公共helper,都已抽离复用,保证数据只有一个入口,这样修改的时候只需修改一处地方。这点非常重要:只要你觉得这个数据有变的可能(不要信产品的话),或者多处用到这个变量,一定要将其定义成变量。
2.表单校验,因为有使用团队内部的表单组件,所以校验这块还是比较规范,相同的校验都已抽离成函数,可复用。
3.一定要写好注释,边码边写。
4.函数一定要解耦,要抽离。切记
5.性能小技巧 高质量代码 奇淫技巧之类的
可优化空间
1.应该利用模块模式,将业务相似可复用的部分抽离成单独的模块,view抽离成页面片,js抽离出模块,只export必要的函数,其他模块require即可。好处:可复用、清晰、不污染全局作用域。迭代时采用了这种模式,确实很方便,很好用。
|
|
2.如果可以用vue,如果重来,我一定选择用vue开发。
3.如果出于兼容性考虑,不能用vue,那可以利用vue的思想。尤其对于增删改查,手动维护一个对象或数组,再手写一个将数据渲染成HTML的函数。每次操作只改变数据,最后再调用渲染函数渲染。用这种方式代替频繁的DOM绑定、获取、修改。好处:处理过程很清晰且bug率低。
4.分工合作的,一定要及时沟通,避免重复不必要的劳动。可复用的模块抽离,不仅仅是自己做的部分,应该从整个项目上进行考虑。
5.业务组件的思想没形成。总以为只有modal、datetimepicker,select2这种才叫组件,其实建立在这些组件之上的,业务逻辑相同的部分,也可以抽离成业务组件。业务组件的通用性没有那么高,大多是自己本次业务出现2次或多次时抽离出来的。但是这样的代码布局很清晰,可复用,应该抽离复用。
留一个功课吧
mock server模拟数据
Ps:先这样吧,后续有新的体会或有更好的方法再更新~~