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

前言

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

1.尽可能不要使用冷门框架或者本身的框架

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

2.尽可能避免全局变量

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

3.尽可能把让文件更好阅读

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

4. 尽可能不要跨平台

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

5. 注释真的很重要

此次这个项目一个很耗时间的地方就是查看它的某些功能的实现。由于只有零星的注释，因此要一步一步才能慢慢理解其中做用。因此注释虽然不会编译到打包文件中，可是请在源码中写清楚注释，不能偷懒，由于之后可能也会出现本身的代码本身不认识的状况。

结语

相信各位都对代码质量有本身的看法，我提到的仅仅是冰山一角，也是我此次接手项目中遇到困难的痛点。可是不免本身的代码会交接给另外一我的。咱们要作到的应该保证挖的坑更好找，更加规整，更加浅，好让后来的人不会绊倒。

原文连接：tech.gtxlab.com/pit.html

---

做者简介： 张栓，人和将来大数据前端工程师，专一于html/css/js的学习与开发。