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

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

為什麼要有規範

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

對於公司內部來說，規範能夠讓質量和期望不偏離正常水平，是支援多人協作的基石。同時，某些約定有奇特的魔力，能夠讓配合井然有序。

規範會限定鬼才的發揮，但會提高庸才的產出。規範的目的就是讓所有人用正常的思維理解正常的東西。

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

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

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

規範制定的資料來源

環境

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

規範的制定需要一定的公司環境支援，你改變的可能是核心人員的習慣，牴觸肯定是有的。在某些公司裡，你的規範可能會遇到很多阻力，你需要慢慢改變，東京不是一天熱起來的。

1、都在忙需求，沒人理規範。 無論從軟體管理的角度來說，還是公司的前途來說，放任需求膨脹、程式碼腐爛的管理人員都是不合格的。這種情況通常發生在小公司。

**2、風險暴露期，故障覆盤會議不斷。**公司的第一代或者第二代程式設計師已經功成身退，留下的坑變成了你現在的工作。要給系統量身定製一套合適的規範，很難，要考慮相容。

**3、垂直部門太多，各自為政。**每個部門都覺得自己的規範牛X，你成為許多撕逼場景的火藥集中地。暗中觀察，故障驅動。

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

資料來源

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

公司內的開發最討厭的就是“我們XX大廠就是這麼幹的”。不好意思，我們水淺王八多，到處是大哥，不吃你這一套。

你需要評估一個規範影響的範圍。比如你搞個編碼規範，物件是最底層逆來順受的碼農，影響就小了點；但如果你做的是後端、前端、測試的統一規範，你就需要承受三方的唾沫。所以溫水煮青蛙，不要打著規範的名義出規範，不積矽步無以至千里，我們們來日方長，細水長流。

規範的切入點

怎麼評估規範實施情況

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

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

**2、實施數量。**有多少的專案已經合規，你需要維護一個大體的進度表，評估整個實施週期。

**3、反對意見。**規範會動一部分人的乳酪，或者守舊派的抵制。你需要找出一個折衷點，不能過分混淆視聽，也需要照顧反對者的情緒。通常，將他們的專案排在最後實施，是通過百分比推動的一種簡單方式。

**4、效果反饋。**一般，規範能夠在效率上、協作上、質量上推進你的工作。一些“最佳實踐“能夠很好的鼓舞整個演進流程。

人工review

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

自動化工具檢測

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

基礎運維和基礎架構是做這些自動化工具最佳的場所。這也是哪怕某個開源方案再成熟，也要封裝上一層的原因：你可以針對約定和規範程式設計。

規範和研發文化的推進

每一種規範，對應著一種公司文化，或者代表公司的不同階段。

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

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

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

範例

例子：Feign jar包的釋出規範。

SpringCloud通過feign方式進行RPC呼叫，我們採用了釋出api jar包的方式進行協作。但隨著專案的增多，jar包的管理成為了顯著的問題。為避免因版本升級、變更引起其他的線上問題，保持線上環境jar包的穩定性，特制定此規範。

jar包依賴

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

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

jar包升級

jar包一旦釋出，必須保證其向下相容的特性，具體體現在：

**一、**不允許修改所提供的欄位的型別，比如由int改成String

**二、**不允許刪除和變更欄位，比如修改欄位的大小寫

**三、**服務提供方需處理某些引數為空的情況，做到向下相容

**四、**對於以上限制無法完成的更改，可提供新的介面和引數，對外暴露新的介面。老介面依然保持可用，直到確認無任何呼叫

**五、**不允許使用多型對介面進行擴充套件，請提供不同的名稱！

**六、**提供清晰的介面引數，不允許萬能介面（老專案可逐步迭代）

**七、**介面變更，必須提供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開發規範了，你自己的程式碼都爛透了，還真以為有通吃的規範啊。