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