1-技術開發規範

命名規範

搭建項目結構的起步過程，應用命名規範、子產品的劃分、目錄（包）的命名，我覺得非常重要，如果做的足夠好，别人導入項目後可能隻需要10分鐘就可以大概了解系統結構。

具體規範包括包命名、類的命名、接口命名、方法命名、變量命名、常量命名。

統一IDE代碼模闆

約定了IDEA/Eclipse IDE代碼的統一模闆，代碼風格一定要統一，避免不同開發人員使用不同模闆帶來的差異化以及代碼merge成本。使用IDEA的同學可以安裝Eclipse Code Formatter插件，和Eclipse統一代碼模闆。

Maven使用規範

所有二方庫、三方庫的版本統一定義到parent pom裡，這樣來所有業務應用工程統一繼承parent pom裡所指定的二方庫、三方庫的版本，統一架構與工具的版本(Spring、Apache commons工具類、日志元件、JSON處理、資料庫連接配接池等)，同時要求生産環境禁用SNAPSHOT版本。這樣以來更新通用架構與工具的版本，隻需要應用工程更新parent pom即可。

代碼Commit規範

基于Angular Commit Message規範生成統一的ChangeLog，這樣一來對于每次釋出release tag非常清晰，Mac下都需要安裝對應的插件，IDEA也有對應的插件，具體可以參考阮一峰老師的《Commit message 和 Change log 編寫指南》。代碼的commit的規範對團隊非常重要，清晰的commit資訊生成的release tag，對于生産環境的故障復原業非常關鍵，能夠提供一些有價值的資訊。

統一API規範

統一Rpc服務接口的傳回值ResultDTO,具體代碼如下

success代表接口處理響應結果成功還是失敗，errorCode、errorMsg表示傳回錯誤碼和錯誤消息，module表示傳回結果集，把ResultDTO定義到common-api頂層二方庫，這樣以來各個應用不需要來回轉換傳回結果。

Http Rest接口規範約定同ResultDTO相差無幾，需要額外關注一下加解密規範和簽名規範、版本管理規範。

異常處理規範

異常處理不僅僅是狹義上遇到了Exception怎麼去處理，還有各種業務邏輯遇到錯誤的時候我們怎麼去處理。service服務層捕獲的異常主要包括BusinessException(業務異常)、RetriableException (可重試異常) 到 common-api，定義一個公共異常攔截器，對業務異常、重試異常進行統一處理，對于可重試的異常調用的服務接口需要保證其幂等性。

另外其他業務層有些特殊異常不需要攔截器統一處理，内部可以進行自我消化處理掉，根據場景對應的處理原則主要包括：

直接傳回

抛出異常

重試處理

熔斷處理

降級處理

這又涉及到了彈力設計的話題，我們的系統往往會對接各種依賴外部服務、Api，大部分服務都不會有SLA，即使有在大并發下我們也需要考慮外部服務不可用對自己的影響，會不會把自己拖死。我們總是希望：

盡可能以小的代價通過嘗試讓業務可以完成；

如果外部服務基本不可用，而我們又同步調用外部服務的話，我們需要進行自我保護直接熔斷，否則在持續的并發的情況下自己就會垮了；

如果外部服務特别重要，我們往往會考慮引入多個同類型的服務，根據價格、服務标準做路由，在出現問題的時候自動降級。

推薦使用Netflix開源的hystrix容災架構，主要解決當外部依賴出現故障時拖垮業務系統、甚至引起雪崩的問題。目前我團隊也在使用，能夠很好的解決異常熔斷、逾時熔斷、基于并發數限流熔斷的降級處理。

分支開發規範

早期的時候源碼的版本管理基于 svn，後來逐漸切換到 git，分支如何管理每一個公司（在Gitflow的基礎上）都會略有不同。

針對分支開發規範，指定如下标準：

分支的定義（master、develop、release、hotfix、feature）

分支命名規範

checkout、merge request流程

提測流程

上線流程

Hotfix流程

雖然這個和代碼品質和架構無關，按照這一套标準執行下來，能夠給整個研發團隊帶領很大的便利：

減少甚至杜絕代碼管理導緻的線上事故；

提高開發和測試的工作效率，人多也亂；

減少甚至杜絕代碼管理導緻的線上事故；

友善運維處理釋出和復原；

讓項目的開發可以靈活适應多變的需求，多人協同開發。

統一日志規範

日志是産品必不可少的一個功能，具備可回溯性、能夠抓取問題現場資訊是其獨一無二的優點，尤其在生産系統上問題定位等方面具有不可替代的作用。

這裡着重強調一下針對異常的日志規範：

WARN和ERROR的選擇需要好好考慮，WARN一般我傾向于記錄可自恢複但值得關注的錯誤，ERROR代表了不能自己恢複的錯誤。對于業務處理遇到問題用ERROR不合理，對于catch到了異常也不是全用ERROR。

記錄哪些資訊，最好列印一定的上下文（鍊路TraceId、使用者Id、訂單Id、外部傳來的關鍵資料）而不僅僅是列印線程棧。

記錄了上下問資訊，是否要考慮日志脫敏問題？可以在架構層面實作，比如自定義實作logback的ClassicConverter。

正确合理的使用日志，能夠指引開發人員快速查找錯誤、定位問題，是以約定了一套日志使用标準規範，現在可以更多的參考《阿裡經濟體開發規約——日志規約》。

統一MYSQL開發規範

表的設計和 Api 的定義類似，屬于那種開頭沒有開好，以後改變需要花10x代價的，我知道，一開始在業務不明确的情況下，設計出良好的一步到位的表結構很困難，但是至少我們可以做的是有一個好的标準。

統一工具與架構

對開發過程中所用到的公共元件進行了統一抽象與封裝，包括 dao 層架構mybatis、cache 元件 jetcache、httpclien t元件、common-tools (公共工具)，同時抽取出全局唯一ID、分布式鎖、幂等等公共元件，把以上公共元件進行內建到各個應用，進行統一更新、維護，這樣以來友善大家将更多的精力集中到業務開發上。