開工大吉！簡單的說說公司的開發規範！

你們好，很久沒有寫公衆號了，最近有朋友參加面試被問到開發規範的問題，忽然發現天天干着工做，卻沒有關注這個問題，就想着寫篇文章，簡單的說下本身公司的開發規範。

關於規範，每一個公司都有本身獨特的開發規範，歸根結底，好的規範才能提升一個團隊的效率，接下來，簡單的說下本身公司的開發規範，若是你們能在其中有所收穫，就是值得的，歡迎評論區交流。

接口規範：

一、在開發以前必需要先定義接口，定義接口就必需要思考你的需求，邏輯，在寫接口文檔的時候其實你就已經在你的大腦中實現了一遍你的需求了。

二、你定義的接口也是要有標準的，包括不包含多餘的字段，正式環境和測試環境的數據格式必須一致，文檔與真實開發出來的接口必須一致等等。

三、在開發的過程當中，若是接口有變化，須要及時和前端或者客戶端溝通，避免由於信息的不一樣步問題而致使工期延誤。

四、還有前端和APP拿到你的接口數據以後不須要再次的進行邏輯處理，好比說，狀態字段是int類型，你把全部的枚舉類型給他，讓他本身去循環判斷應該顯示哪一個中文，若是接口定義成這樣，那這個接口就是不太合格的，你能夠在接口返回數據中添加一個字段來避免使用者的多餘的工做量。

上線規範：

一、首先在開發完成後，咱們須要自測，自測的標準並非特別的高，只須要經過冒煙測試，可以把正常的流程走通就能夠了，千萬不要自測還沒測好就交給測試，當測試辛辛苦苦的錄完數據，走正常的流程的時候報個系統異常，這種心情應該是十分酸爽的。只有當這些常規的測試走通的時候，測試纔會給你測那些比較不容易發現的問題，若是測試老是在這些顯而易見的問題上兜兜轉轉，那麼在有限的時間內，測出的產品可能質量也並不高。

二、其次測試經過以後，關注下在正式環境上是否須要資源申請，好比說服務器，redis，數據庫，這些東西須要提早的給運維提交工單，讓運維可以從容不迫的去準備，避免在上線那天由於資源還沒準備好而耽誤太長的時間。

三、在測試經過，運維準備好資源的時候，就能夠部署到線上了，咱們的代碼如今應該是在dev分支上，咱們須要把代碼合併到master分支上（這裏須要說明下，master分支上千萬不要修改代碼，咱們要時刻保證master分支上的代碼是和線上環境保持一致的），以後就能夠經過Jenkins或者其餘部署工具部署項目了。

四、部署以後，咱們不能直接通知測試來測試了，咱們須要用咱們的測試用例，本身先訪問下咱們的正式環境的接口，看下是否正常，以後在通知測試回測。等待着測試彙報答覆（每次上線聽到測試說沒有問題，內心豁然開朗）上線完成。

這裏說下，在線上部署的同時須要注意的點，在dev和master分支合併代碼以後要進行代碼review，避免本身的誤操做帶來沒必要要的問題。

當在正式環境遇到問題的時候，咱們須要先經過本身的測試用例來定位問題，能夠單點線上tomcat來肯定服務是否存在代碼問題，若是是代碼問題，修改後第二次合併代碼的時候要慎重，可使用交叉review的方式。若是問題歸屬配置問題，及時找運維溝通解決。上線完成後，要對master分支上打tag，在tag中說明這次部署上線的主要內容。

以上只是簡單的說了下接口文檔和上線的規範，接下來還會說數據庫設計相關的規範，做爲本身的知識總結，也但願能幫助到其餘人。

這裏會長期的分享技術乾貨、平常工做總結與思考，你的點贊和分享是對我最大的支持，感謝。

若是這篇文章讓你有所收穫，歡迎關注公衆號 java技術情報局