前言：
作爲一個技術負責人，不能只定義一個項目的技術選型，而不注意開發細節。
開發前，如果不預先定義好規範，那麼項目中就會亂成一鍋粥。每個人自成一派，單看每個人的模塊，貌似都沒啥大問題，但合在一起，就明顯感覺是多個人開發的。這個時候，等發發現問題，再讓某些人去改的話，一方面容易引起coder的反對，另一方面也會減少技術負責人的威望。因爲一般出現這種情況，大部分原因是項目的技術負責人不合格，沒有把事情提前想好，也就是所謂的沒有經驗。
那麼，如何才能當一個合格的技術負責人呢？如何去定這些規則呢？
1、git規範
現在開發對於版本控制，最多就是git了，所以以git爲例，講講通用的規則。
一般線上分支是master，保證上線部署的必須是master分支的代碼。
開發總分支是dev分支。
普通的開發分支一般是dev_業務內容，這個其實就沒有那麼多限制了。
1、新代碼開發完成後，本地環境自測，測到通過。
2、然後合到dev後，上測試環境測試，測到通過。
3、最後code review，然後由技術負責人或者指定的一位大佬將dev的代碼合到master。
4、master分支上線，上線後再次測試驗證。
對於普通的開發人員：
所有關於master的操作一律禁止。
開發完成並且自測通過後，只需要將自己開發分支的代碼merge到dev分支，然後將devf分支部署到測試環境，測試通過即可。
所有新分支都從dev分支拉出來，切勿從master分支拉代碼。
dev分支，不允許普通的開發人員直接提交。
對於技術負責人或技術負責人指定的開發大牛
負責dev代碼的codereview。
負責將dev代碼合到master。（gitlab中有merge request，直接審批也可以）
2、數據庫規範
數據庫相關的，有些事情需要提前規範好。比如：
1、每個表中，都要帶有create_time和update_time字段，時間類型。
2、每個表中，都必須有自增id字段，bigint類型。
3、具體業務中，常用單詞的英文翻譯，需要提前定義好。比如企業員工，有人用user，有人用staff，其實用哪個都可以，重在統一，提前要說好，比如都用user。
4、sql規範，比如查詢禁止使用select *，禁止表連接等等。
5、數據的刪除，都是邏輯刪除，del=1代表已刪除，del=0代表未刪除，禁止使用delete語句物理刪除數據。
6、複雜業務的庫表，必須先設計，後開發。技術負責人應該把所有設計都過一遍，避免返工。
3、包結構規範
1、比如項目實體統一放在entity包下，dao層統一放在dao包下，service，controller同理。
2、比如service使用面向接口編程，統一先定義接口，再實現接口。比如userService接口和userServiceImpl實現類。
3、提前給同學們說明項目中dto，vo等對象的含義以及使用場景。
4、提前根據項目要求，提供出一些公共的util，比如文件上傳下載，excel導入導出，校驗等等，這個不強求，如果項目中開發人員普遍技術水平較高，可由開發同學自己編寫，但需要定一套統一的util，避免重複開發。比如excel的導入導出，可能有人用easyexcel，也有人直接用poi，這樣poi的包版本就有可能和easyexcel中引用的poi包版本衝突。
4、代碼質量檢測工具
如果代碼量過大，沒有人力去codereview，那就要用一些代碼檢測工具了。比如統一使用CheckStyle插件，也可以自定義一些檢查規範。
這個也是代碼的終極規範了。但不要完全依賴，只不過是一些明顯的錯誤可以被挖出來了，一些偏業務的坑，還是需要codereview的。
個人經驗，基本上看一個人寫代碼，看他寫100行的核心代碼，就知道這個人的代碼的大概質量了。