最近公司來了個實習生，我看來一下它提交的程式碼。整個人都不好了
希望大家引以為戒，不要讓自己的程式碼堆成屎山！
一、程式碼規範問題
首先我們來看我們的前端部分
如果不去做程式碼的規範，那麼會出現生命問題呢？
以下程式碼規範出自阿里前端團隊專案開發規範
我們發現在專案中，有很多的地方都是存在程式碼不規範的問題，要知道，如果程式碼或者專案的風格不同意，程式碼不規範，就會導致涼涼，特別是後續改程式碼 ，改需求的時候就涼涼了，會導致工作量暴漲
--現在我們來看看，目前專案中存在的問題
目錄結構不清晰
程式碼風格不統一
總結
你不覺得，如果我們後期需要維護，那麼這種程式碼的維護成本，還有找bug的成本將會非常非常的高嗎？，這些就是傳說中的屎山
HTML部分的程式碼規範問題
這裡我們主要來研究，我們的HTML部分還有CSS部分的相關問題，
JS部分的程式碼規範問題
Vue部分的程式碼規範問題
以上的代規範，是比較通俗，且易懂的規範，請大家好好遵守，這樣，以後面試官你看你程式碼，就知道你是工作的過的人，所以啊，千萬不要讓你的程式碼風格堆成“屎山”
文件的規範地址，這一套文件基於阿里團隊的開發規範，所以啊，你值得擁有，這樣不是我定，對標大公司，希望各位對自己的要求高一些
https://github.com/BM-laoli/smart-admin
小程式/APP部分的程式碼規範問題
這個部分我們後面再說吧，基本上和vue等框架中的約定是一樣的。
二、專案版本控制問題
程式碼不規範，親人兩行淚血淋淋的教訓
下面就是我們兩個人的垃圾git提交，你可以想想一下，這僅僅是兩個人的專案，如果是四五個人的，七八個人的專案，git版本控制會亂成什麼樣子！！！
嚴格控制master分支
不要去改別人分支上的東西，你自己的怎麼折騰怎麼衝突，都請在你自己的分支倒騰
嚴格控制控制分支程式碼提交的流程
如何規範？
這裡我收藏了兩個主要git規範
下面的主要是兩個方面來管理我們的GIT專案，前者從面的角度出發，後者從點的角度出發
-
一線大廠的commit程式碼提交規範
https://blog.csdn.net/DevolperFront/article/details/104624183/
三、關於團隊協作的問題
誤區
不要不敢問，這有啥的，問就是，提要求就是！
要知道，我們開發是前後端一起配合的團隊，有需求的變化，就要和後臺的說，必須說，不要自己想著在前端自己寫東西解決，說不定，後端就你加幾個欄位就能解決，你一天的開發量的問題。所以說，和後端的開發協調溝通是非常非常非常的重要的
'對於假資料'的問題
你的假資料千萬不要自己，想怎麼寫，就怎麼寫，那樣就很蛋疼，而且會白白的增加你的工作量，如果你的功能確確實實需要資料才能實現，那麼你需要和後臺協調好，看看開發文件，資料到底是什麼樣的，再去寫好吧，不要自己想著，這樣定義資料結構就很容易實現這樣的功能，然後就去寫，到時候介面一出來，如果大面積不對，那麼你就老老實實加班把！！！血的經驗！
技術公司的選人標準
如果有A /B兩個人，做了同一個專案 ，都拿去面試，A做不是很全，但是它負責的功能 完美度85%,做得非常非常的好， 而B大面積的完成了整專案，對於用人單位來說，跟願意錄取A，而不是B
總結經驗就是：‘有時會深度是非常的重要的’，因為我們前端首要考慮的就是使用者的體驗！細節要到位，功能要Nice，要漂亮
進行溝通協調的工具
禪道，icafe.....
介面的測試工具
雖然我們是前端，但是也是需要懂得一部分的後端的業務邏輯，有時間有精力的同學可以去學習一些Pyhton還有java方面的知識
推薦使用ApiPost國產版的PostMan
如果想使用輕量級的東西，就可以使用VS提供的REST外掛（非常好用）