前言

前段時間，接手了一個外包公司給我們公司做的專案頁面,整體修改下來苦不堪言，這段填坑經歷也讓我理解到了程式碼質量與程式碼後面持續性維護的重要性。不能舒服了自己，噁心了下一個接手人。我就以這次這個專案的一絲絲感受分享給大家。

1.儘量不要使用冷門框架或者自己的框架

這次這個專案的第一個噁心點就是他使用的是他們自己內部的框架(聽說是自己框架，也可能開源了)，網上搜不到任何可以幫助的資訊。遇到了問題的時候我就只能一步步的去試，或者看一下頁面其他模組類似功能部分是如何寫的，大大降低了我的效率和精力。所以做專案，儘量使用成熟度和使用度更加高的熱門框架。若一定要用自己的或者冷門的框架，請一定要寫一份詳細的文件，方便以後填坑人快速填坑。

2.儘量避免全域性變數

我雖然沒有深入研究這個框架，但是也瞭解了其中的一些機制。它是一顆全域性樹，然後不同元件的所有方法變數都掛在這棵樹上了。通過框架的監聽，在html繫結一個元素後，全域性樹上同樣會為這個元素的所有方法做出定義。也就是說不管我有沒有用到這個元素的某個方法，它都會給你定義出來給你去使用，對程式碼量的消耗無疑是巨大的。所以整個全域性樹的檔案程式碼量將近一萬行。雖然我做修改的時候對我影響不大，但是覺得以後編碼過程中儘量避免使用全域性變數。

3.儘量把讓檔案更好閱讀

我覺得小專案是可以按檔案型別來分類的，但是涉及到元件大幾十個的時候,就眼花繚亂了。我不得不借助IDE的搜尋功能來找到檔案。一個js資料夾中密密麻麻的檔案看的人頭疼，當然也包括html資料夾。更好的應該是元件所需要的檔案都放在同一個資料夾內，這可能與個人的編碼習慣有關了，養成良好的習慣利己利人。

4. 儘量不要跨平臺

這是我最想吐槽的一點了。同樣的前端框架，vue,react 等都可以在windows上編碼執行，為什麼你要在liunx上才能跑起來？？？耗費近一天時間裝好docker才能將你跑起來。所以編寫的程式碼千萬不要出現跨平臺的情況，弄得後來接手的人一臉懵逼。就算你寫了再詳細的說明，就算你寫了再強大的指令碼，在不會這個系統的人面前也是做無用功。只會讓後來的人心裡不舒服。

5. 註釋真的很重要

這次這個專案一個很耗時間的地方就是檢視它的某些功能的實現。因為只有零星的註釋，所以要一步一步才能慢慢理解其中作用。所以註釋雖然不會編譯到打包檔案中，但是請在原始碼中寫清楚註釋，不能偷懶，因為以後可能也會出現自己的程式碼自己不認識的情況。

結語

相信各位都對程式碼質量有自己的見解，我提到的僅僅是冰山一角，也是我這次接手專案中遇到困難的痛點。但是難免自己的程式碼會交接給另一個人。我們要做到的應該保證挖的坑更好找，更加規整，更加淺，好讓後來的人不會絆倒。

---

作者簡介： 張栓，人和未來大資料前端工程師，專注於html/css/js的學習與開發。