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

前言

前段時間，接手了一個外包公司給咱們公司作的項目頁面,總體修改下來苦不堪言，這段填坑經歷也讓我理解到了代碼質量與代碼後面持續性維護的重要性。不能舒服了本身，噁心了下一個接手人。我就以此次這個項目的一絲絲感覺分享給你們。

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

此次這個項目的第一個噁心點就是他使用的是他們本身內部的框架(據說是本身框架，也可能開源了)，網上搜不到任何能夠幫助的信息。遇到了問題的時候我就只能一步步的去試，或者看一下頁面其餘模塊相似功能部分是如何寫的，大大下降了個人效率和精力。因此作項目，儘可能使用成熟度和使用度更加高的熱門框架。若必定要用本身的或者冷門的框架，請必定要寫一份詳細的文檔，方便之後填坑人快速填坑。

2.儘可能避免全局變量

我雖然沒有深刻研究這個框架，可是也瞭解了其中的一些機制。它是一顆全局樹，而後不一樣組件的全部方法變量都掛在這棵樹上了。經過框架的監聽，在html綁定一個元素後，全局樹上一樣會爲這個元素的全部方法作出定義。也就是說無論我有沒有用到這個元素的某個方法，它都會給你定義出來給你去使用，對代碼量的消耗無疑是巨大的。因此整個全局樹的文件代碼量將近一萬行。雖然我作修改的時候對我影響不大，可是以爲之後編碼過程當中儘可能避免使用全局變量。

3.儘可能把讓文件更好閱讀

我以爲小項目是能夠按文件類型來分類的，可是涉及到組件大幾十個的時候,就眼花繚亂了。我不得不借助IDE的搜索功能來找到文件。一個js文件夾中密密麻麻的文件看的人頭疼，固然也包括html文件夾。更好的應該是組件所須要的文件都放在同一個文件夾內，這可能與我的的編碼習慣有關了，養成良好的習慣利己利人。

4. 儘可能不要跨平臺

這是我最想吐槽的一點了。一樣的前端框架，vue,react 等均可以在windows上編碼運行，爲何你要在liunx上才能跑起來？？？耗費近一天時間裝好docker才能將你跑起來。因此編寫的代碼千萬不要出現跨平臺的狀況，弄得後來接手的人一臉懵逼。就算你寫了再詳細的說明，就算你寫了再強大的腳本，在不會這個系統的人面前也是作無用功。只會讓後來的人內心不舒服。

5. 註釋真的很重要

此次這個項目一個很耗時間的地方就是查看它的某些功能的實現。由於只有零星的註釋，因此要一步一步才能慢慢理解其中做用。因此註釋雖然不會編譯到打包文件中，可是請在源碼中寫清楚註釋，不能偷懶，由於之後可能也會出現本身的代碼本身不認識的狀況。

結語

相信各位都對代碼質量有本身的看法，我提到的僅僅是冰山一角，也是我此次接手項目中遇到困難的痛點。可是不免本身的代碼會交接給另外一我的。咱們要作到的應該保證挖的坑更好找，更加規整，更加淺，好讓後來的人不會絆倒。

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

---

做者簡介： 張栓，人和將來大數據前端工程師，專一於html/css/js的學習與開發。