如何避免前人挖坑,后人填坑

前言

前段时间,接手了一个外包公司给我们公司做的项目页面,整体修改下来苦不堪言,这段填坑经历也让我理解到了代码质量与代码后面持续性维护的重要性。不能舒服了自己,恶心了下一个接手人。我就以这次这个项目的一丝丝感受分享给大家。

1.尽量不要使用冷门框架或者自己的框架

这次这个项目的第一个恶心点就是他使用的是他们自己内部的框架(听说是自己框架,也可能开源了),网上搜不到任何可以帮助的信息。遇到了问题的时候我就只能一步步的去试,或者看一下页面其他模块类似功能部分是如何写的,大大降低了我的效率和精力。所以做项目,尽量使用成熟度和使用度更加高的热门框架。若一定要用自己的或者冷门的框架,请一定要写一份详细的文档,方便以后填坑人快速填坑。

2.尽量避免全局变量

我虽然没有深入研究这个框架,但是也了解了其中的一些机制。它是一颗全局树,然后不同组件的所有方法变量都挂在这棵树上了。通过框架的监听,在html绑定一个元素后,全局树上同样会为这个元素的所有方法做出定义。也就是说不管我有没有用到这个元素的某个方法,它都会给你定义出来给你去使用,对代码量的消耗无疑是巨大的。所以整个全局树的文件代码量将近一万行。虽然我做修改的时候对我影响不大,但是觉得以后编码过程中尽量避免使用全局变量。

3.尽量把让文件更好阅读

我觉得小项目是可以按文件类型来分类的,但是涉及到组件大几十个的时候,就眼花缭乱了。我不得不借助IDE的搜索功能来找到文件。一个js文件夹中密密麻麻的文件看的人头疼,当然也包括html文件夹。更好的应该是组件所需要的文件都放在同一个文件夹内,这可能与个人的编码习惯有关了,养成良好的习惯利己利人。

4. 尽量不要跨平台

这是我最想吐槽的一点了。同样的前端框架,vue,react 等都可以在windows上编码运行,为什么你要在liunx上才能跑起来???耗费近一天时间装好docker才能将你跑起来。所以编写的代码千万不要出现跨平台的情况,弄得后来接手的人一脸懵逼。就算你写了再详细的说明,就算你写了再强大的脚本,在不会这个系统的人面前也是做无用功。只会让后来的人心里不舒服。

5. 注释真的很重要

这次这个项目一个很耗时间的地方就是查看它的某些功能的实现。因为只有零星的注释,所以要一步一步才能慢慢理解其中作用。所以注释虽然不会编译到打包文件中,但是请在源码中写清楚注释,不能偷懒,因为以后可能也会出现自己的代码自己不认识的情况。

结语

相信各位都对代码质量有自己的见解,我提到的仅仅是冰山一角,也是我这次接手项目中遇到困难的痛点。但是难免自己的代码会交接给另一个人。我们要做到的应该保证挖的坑更好找,更加规整,更加浅,好让后来的人不会绊倒。


作者简介: 张栓,人和未来大数据前端工程师,专注于html/css/js的学习与开发。