架構師負責訂規範，你負責執行！

心意相通的研發之間，本不須要BB這BB那搞些約束。但寧教我心徒枉然，不教銀光惹塵埃。過度的放縱愛自由，那就是一去不復返了。

本文系稍成點系統的碎碎語，若有共鳴，拍掌，麼！

爲何要有規範

規範是一種束縛，是騰飛前的最後一步加速。大公司免費開源複雜的軟件，有一個很是重要的目的就是想要佔據特殊解決方案的標準制定，想要一個話語權；一項技術趨向成熟的一個標誌也是標準、規範的制定。

對於公司內部來講，規範可以讓質量和指望不偏離正常水平，是支持多人協做的基石。同時，某些約定有奇特的魔力，可以讓配合井井有理。

規範會限定鬼才的發揮，但會提升庸才的產出。規範的目的就是讓全部人用正常的思惟理解正常的東西。

沒錯，規範就是把你變成一個釘子。不管你是紋釘仍是自攻螺釘，都會用一把錘子給敲下去！規範是一種對功能的閹割和重排序。

臭名昭著的阿里釘釘，釘釘的意思明白了吧。

你即便再牛逼，也給規範按到地，給的工資也就那熊樣！打工很難致富，我想這就是緣由。

規範制定的數據來源

環境

不落地的規範，設計的再好，也是廢物。

規範的制定須要必定的公司環境支持，你改變的多是核心人員的習慣，抵觸確定是有的。在某些公司裏，你的規範可能會遇到不少阻力，你須要慢慢改變，東京不是一天熱起來的。

一、都在忙需求，沒人理規範。 不管從軟件管理的角度來講，仍是公司的前途來講，聽任需求膨脹、代碼腐爛的管理人員都是不合格的。這種狀況一般發生在小公司。

**二、風險暴露期，故障覆盤會議不斷。**公司的第一代或者第二代程序員已經功成身退，留下的坑變成了你如今的工做。要給系統量身定製一套合適的規範，很難，要考慮兼容。

**三、垂直部門太多，各自爲政。**每一個部門都以爲本身的規範牛X，你成爲許多撕逼場景的火藥集中地。暗中觀察，故障驅動。

**四、外包。**還要個錘子規範，都是甲方給你訂的。尾款別要了直接跑路吧。

數據來源

只有深刻業務開發，纔有資格進行規範的制定。自覺得是、閉門造車是不可取的。即便你的思路再怎麼好，可能到了另一個公司就會水土不服。

公司內的開發最討厭的就是「咱們XX大廠就是這麼幹的」。很差意思，咱們水淺王八多，處處是大哥，不吃你這一套。

你須要評估一個規範影響的範圍。好比你搞個編碼規範，對象是最底層逆來順受的碼農，影響就小了點；但若是你作的是後端、前端、測試的統一規範，你就須要承受三方的唾沫。因此溫水煮青蛙，不要打着規範的名義出規範，不積硅步無以致千里，我們來日方長，細水長流。

規範的切入點

怎麼評估規範實施狀況

其實，規範這個東西，一個自上而下的強制性措施是比較好的。規範的review應該逐漸造成文化，或者流程中的一部分。但要結合如下特徵進行規範的修正。

**一、實施難度。**你的規範是否過於繁雜，很差記憶和實施，佔據了研發大量的時間。

**二、實施數量。**有多少的項目已經合規，你須要維護一個大致的進度表，評估整個實施週期。

**三、反對意見。**規範會動一部分人的奶酪，或者守舊派的抵制。你須要找出一個折衷點，不能過度混淆視聽，也須要照顧反對者的情緒。一般，將他們的項目排在最後實施，是經過百分比推進的一種簡單方式。

**四、效果反饋。**通常，規範可以在效率上、協做上、質量上推動你的工做。一些「最佳實踐「可以很好的鼓舞整個演進流程。

人工review

常常組織項目review會議，經過不斷的重複達到你的目的。提早找出項目中的典型案例，對不合規的代碼指出建設性的改進。注意必定要提早了解項目，半吊子的review只會讓別人對規範的正確性產生懷疑。

自動化工具檢測

將規範抽象成一系列工做流，使用支撐工具進行過濾。經過不斷的負反饋進行推動。好比，某些jar包的衝突檢測、命名方式，均可以在持續集成系統中進行判斷。研發只要錯上一兩次，這種約定就基本上在腦海中了。

基礎運維和基礎架構是作這些自動化工具最佳的場所。這也是哪怕某個開源方案再成熟，也要封裝上一層的緣由：你能夠針對約定和規範編程。

規範和研發文化的推動

每一種規範，對應着一種公司文化，或者表明公司的不一樣階段。

趨向謹慎的公司，會選擇複雜的流程規範，制約全部員工的活動，避免越軌操做。此類公司生產事故會比較少，由於戰線拉的很長很長，使用普通員工的人海戰術便可完成工做。

本性活潑的公司，流程規範會比較輕量，經過高質量的研發對約定的認同來演進產品。是創新的土壤，對新需求響應快速。

規範和研發文化相輔相成，伉儷情深。

範例

例子：Feign jar包的發佈規範。

SpringCloud經過feign方式進行RPC調用，咱們採用了發佈api jar包的方式進行協做。但隨着項目的增多，jar包的管理成爲了顯著的問題。爲避免因版本升級、變動引發其餘的線上問題，保持線上環境jar包的穩定性，特制定此規範。

jar包依賴

發佈的api jar包應該儘可能少的依賴其餘資源。也就是dependencies部分應該越少越好。依賴必須加入<scope>provided</scope>，版本交由使用方說明。

jar包的名稱和提供的內容，必須可讀：可以根據字面意思猜想其功能。

jar包升級

jar包一旦發佈，必須保證其向下兼容的特性，具體體如今：

**1、**不容許修改所提供的字段的類型，好比由int改爲String

**2、**不容許刪除和變動字段，好比修改字段的大小寫

**3、**服務提供方需處理某些參數爲空的狀況，作到向下兼容

**4、**對於以上限制沒法完成的更改，可提供新的接口和參數，對外暴露新的接口。老接口依然保持可用，直到確認無任何調用

**5、**不容許使用多態對接口進行擴展，請提供不一樣的名稱！

**6、**提供清晰的接口參數，不容許萬能接口（老項目可逐步迭代）

**7、**接口變動，必須提供wiki文檔

版本號

項目採用三段版本管理，如 2.8.15

版本段	意義
2	大版本迭代，通常是很是重要的技術升級或者業務重構
8	重要的bug修改和大版本迭代
15	大版本迭代中的bug修改，依次遞增

不接受非三段的版本號！jar包不接受覆蓋式發佈，需升版本號！

jar包類型

以SNAPSHOT結尾的jar包

如 order-api-1.0.1-SNAPSHOT.jar ，SNAPSHOT爲大寫。

研發使用dev帳號發佈的jar包，以SNAPSHOT結尾，不帶SNAPSHOT的沒法發佈到私服。

SNAPSHOT在非線上環境使用，供研發調試接口、測試功能，請在上線前去掉SNAPSHOT，並告知SRE發佈正式jar包。

此種jar包全部人都有權限發佈，依賴項目只拉取最新的jar包，各項目成員自行解決開發測試中的衝突問題。

mvn dependency:tree 命令能夠查看全部的jar包

不帶SNAPSHOT的jar包

如 order-api-1.0.1.jar

線上正式環境使用，使用SNAPSHOT結尾的jar包上線，會打包失敗。

此種jar包僅SRE有權限發佈。

jar包信息維護

因爲jar包數量多，功能繁雜，須要維護jar包的變動信息。

目前使用wiki維護jar包的升級信息。

結尾

規範這東西，不能亂搬。小螺絲扣大螺母，和沒套有啥區別？

嘿，說的就是你，先別搬什麼阿里java開發規範了，你本身的代碼都爛透了，還真覺得有通吃的規範啊。