大家好，好久沒有寫公眾號了，最近有朋友參加面試被問到開發規範的問題，突然發現每天干著工作，卻沒有關注這個問題，就想著寫篇文章，簡單的說下自己公司的開發規範。
關於規範，每個公司都有自己獨特的開發規範，歸根結底，好的規範才能提高一個團隊的效率，接下來，簡單的說下自己公司的開發規範，如果大家能在其中有所收穫，就是值得的，歡迎評論區交流。
介面規範：
1、在開發之前必須要先定義介面，定義介面就必須要思考你的需求，邏輯，在寫介面文件的時候其實你就已經在你的大腦中實現了一遍你的需求了。
2、你定義的介面也是要有標準的，包括不包含多餘的欄位，正式環境和測試環境的資料格式必須一致，文件與真實開發出來的介面必須一致等等。
3、在開發的過程中，如果介面有變化，需要及時和前端或者客戶端溝通，避免因為資訊的不同步問題而導致工期延誤。
4、還有前端和APP拿到你的介面資料之後不需要再次的進行邏輯處理，比如說，狀態欄位是int型別，你把所有的列舉型別給他，讓他自己去迴圈判斷應該顯示哪個中文，如果介面定義成這樣，那這個介面就是不太合格的，你可以在介面返回資料中新增一個欄位來避免使用者的多餘的工作量。
上線規範：
1、首先在開發完成後，我們需要自測，自測的標準並不是特別的高，只需要通過冒煙測試，能夠把正常的流程走通就可以了，千萬不要自測還沒測好就交給測試，當測試辛辛苦苦的錄完資料，走正常的流程的時候報個系統異常，這種心情應該是十分酸爽的。只有當這些常規的測試走通的時候，測試才會給你測那些比較不容易發現的問題，如果測試總是在這些顯而易見的問題上兜兜轉轉，那麼在有限的時間內，測出的產品可能質量也並不高。
2、其次測試通過之後，關注下在正式環境上是否需要資源申請，比如說伺服器，redis，資料庫，這些東西需要提前的給運維提交工單，讓運維能夠從容不迫的去準備，避免在上線那天因為資源還沒準備好而耽誤太長的時間。
3、在測試通過，運維準備好資源的時候，就可以部署到線上了，我們的程式碼現在應該是在dev分支上，我們需要把程式碼合併到master分支上（這裡需要說明下，master分支上千萬不要修改程式碼，我們要時刻保證master分支上的程式碼是和線上環境保持一致的），之後就可以通過Jenkins或者其他部署工具部署專案了。
4、部署之後，我們不能直接通知測試來測試了，我們需要用我們的測試用例，自己先訪問下我們的正式環境的介面，看下是否正常，之後在通知測試回測。等待著測試彙報答覆（每次上線聽到測試說沒有問題，心裡豁然開朗）上線完成。
這裡說下，線上上部署的同時需要注意的點，在dev和master分支合併程式碼之後要進行程式碼review，避免自己的誤操作帶來不必要的問題。
當在正式環境遇到問題的時候，我們需要先通過自己的測試用例來定位問題，可以單點線上tomcat來確定服務是否存在程式碼問題，如果是程式碼問題，修改後第二次合併程式碼的時候要慎重，可以使用交叉review的方式。如果問題歸屬配置問題，及時找運維溝通解決。上線完成後，要對master分支上打tag，在tag中說明此次部署上線的主要內容。
以上只是簡單的說了下介面文件和上線的規範，接下來還會說資料庫設計相關的規範，作為自己的知識總結，也希望能幫助到其他人。
這裡會長期的分享技術乾貨、日常工作總結，你的點贊、轉發和收藏是對我最大的支援，感謝。
