杂谈向-关于我重构了公司后台的事
# 关于我重构了公司后台的事
这个项目开始在本周周一(5月18日后),距离5月初入职到现在也有一段时间了,对公司业务有大体的了解了,实在最早刚刚入职时,我就产生了这个计划,并尝试实施了一部分,得到了学长(也是我的领导)的支持,经过了这一周的折腾,也确实初见成功,总结了一下这周发生的事,我写了这篇博客,用于记录所学。
write at 2020/05/22
# 为什么要重构
项目重构其实对于公司来说应该是家常便饭,技术更新每天都在发生,新的技术确实在某些时候会给我们带来更多的效益,但是也并不是所有的新技术都是如此,从换位思考的角度上说,你可能觉得你岗位上前面人的代码很烂、技术很老套之类的,但是对应一下项目时间,或许这正是当时最为新鲜、主流、炙手可热的技术,或许随之诞生了大量的工作岗位。所以让你觉得不舒服想要重构它的原因可以是技术老旧,但是更应该从中反思,到底是什么才让你觉得真的难受想要重构它。
就比如我所在的项目组中(其实就我一个人hhh,需要帮助时候问我学长),项目git日志从4年前开始,那时候正式node火起来的时候,但是很多人都是从前端投奔后端,用着那时候还是主流的jQuery、事件模式的写法去写后端。emmm...不是说不行,只是可读性成了后面几年来,全公司接触过这部分代码的人难忘的痛。
他不是顺序结构、到处充斥着callback、EventProxy,你没办法按顺序看完整个项目,写起来时候也不会带来类型提示,没有MVC结构、前端页面不分离,确实很4年前,让我看完一度认为我在考古。所以,在我写了一组demo后,我和学长评估了一下,很有必要重构这个项目。
# 重构要注意什么
接着前面说,追求新技术去重构一个项目是可行的,但是怎么应用新技术又不让后人觉得写起来难受才是一个好的重构需要具备的。
首先从项目规范、可读性、模块可复用度说起,最好的解决项目可读性的方法就是一刀切,把项目分成多个模块,各自为政。但是对于一个项目来说,你想一刀斩透没那么简单,因为写的时候在一起,所以切开一定是一种藕断丝连的状态。合理的分层、分化往往比直接项目打散的可行性更大。
# 重构实施
其实这次实施的框架是我在离开学校之前就已经成型的构想或者也可以说应用到了一些项目上的雏形项目结构,但是把他应用到正在线上运行的项目上也确实是个挑战。
为了线上考虑,我并没有全切到新的或者说另起炉灶。我在原有的结构的顶层注入了我的项目入口,没有破坏原有的。为了可读性,通篇采用了typescript,这里不是说弱类型不好,但是对于后端开发来说,弱类型或者没有类型是真的会给开发带来麻烦,而且还有可能引发bug。比如这个后台项目和一个前台项目共用了一个mongo数据库,前台插入时间的格式是字符串,后台采用时间戳的方式去搜索在范围内的数据,发现总是空的,直到后来查了一下数据库,里面存的都是字符串。
前台另开了一个项目,用的vue+ts,用ts同样是为了可读性,没有过多说的,同样是用了vuex、vue-router这些全家桶系列的东西,因为这些可读性、操作性都确实是不错,至少对于现在是和其他两个(React、Angular)并列最好的了
特别要说的一点,做了一个框架或者结构,一定要写好文档,让后面接手的人能够遵循你定下的规则或者说沿着你的构想去写。
# 总结篇
从某种角度上讲,重构确实是个体力活,但是你可以在重构中构想,我这样设计后人会不会骂我,哪里还可以加强,因为项目永远不是一个人的事,不要本着一个人能行的想法写嗨了、走远了。
一套项目框架、结构总会是代表着你当前编码水平和以当前水平能做到的最好的思想结晶。