除了老闆之外，我想大多數人是討厭規則的，因為它束縛了我們的自由。然而，無論是個人，還是組織，規則卻是發展中必不可少的環節，雖然我們很難看出規則的直接價值。
研發類任務，更是一類嚴謹的工作，它不僅需要嚴謹的邏輯思維能力，更需要一個完善的研發規範流程。對於程式設計師的我們，其實我們心裡是比較討厭規則的，在我們心裡，只要把需求完成，上線就ok了，其他都是浮雲，其實，這樣的心裡，我以前也是有過。
那麼，一個標準的合理的研發規範，應該是怎樣的？
這篇文章，我將與大家分享自己認為的研發規範化應該是怎樣的， 若有任何問題，請大家及時在評論區提出與交流。
1 範圍
本規範適用於【技術部-各組】所有關聯的相關人員，如產品、開發、測試、運維等，技術部相關人員應嚴格遵守並執行。
2 目的
俗話說，“不以規矩不成方圓”，磨刀不誤砍柴工，良好的文件和文件管理是專案或產品成功的關鍵要素之一，它能有效地解決專案開發中的極大部分問題，如業務規範，開發人員職責劃分，技術規範，專案管控、專案測試、專案上線、專案運營、bug追蹤等問題。
無論是傳統的瀑布式開發、敏捷開發，devops，還是多種方式結合的開發模式，標準流程萬變不離其宗，均可抽象成標準流程。
3 需求如何流轉
需求如何流轉？這是個標準化流程問題。根據我多年的研發、架構、團隊管理等經驗，與大家分享我的見解。
我個人認為，一個正常的需求流程應具備如下關鍵環節。
在實際研發中，不必完全按照該流程流轉，我的建議是模組及模組以上的需求，按照該標準流程，模組及以下的需求，可根據實際情況，參照該流程的區域性流程即可。
3.1 需求維度
關於需求，應包含如下五大階段：
3.1.1 需求提出
需求提出為需求整個階段的首要環節。對需求的後續環節影響非常大，因此良好的需求提出至關重要，為此，需求提出人員應做到如下兩個方面：
（一）明確需求
明確需求，提供如下參考意見：
1.該需求背景是什麼？
2.該需求主要解決什麼業務問題？
3.決定該需求成敗的關鍵因素有哪些？
4.該需求涉及到哪些業務領域？
5.該需求涉及到公司哪些相關部門？
6.該需求的的調研方式有哪些？
7.該需求的成本，如開發成本，人力成本等
（二）需求應具備相關要素
3.1.2 需求調研
需求調研為需求五大階段的第二環節。採用的調研方式，調研結果直接影響需求的準確性，因此需求調研是非常重要，不可或缺的部分。
需求調研必須要解決需求提出階段（一）明確需求的幾個重要問題。
當調研結束後，要對調研的結果，獲取的資料進行提取，加工，轉換和分析，然後將分析的結果形成文件，並以一定的形式展示出來，方便後期需求評審等一系列工作。
3.1.3 需求定義
需求定義為需求五大階段的第三環節。當完成需求調研後，需求攥寫人要對需求五大階段第二環節認真分析，並在需求調研人的協助下完成需求文件的編寫，當完成需求的定義及分析後，需要將此過程書面化，要遵循既定的規範將需求形成書面的文件，我們通常稱之為《需求分析說明書》。
需要注意的是，關於晦澀的業務需求點，需求攥寫人應借必要工具進行建模分析，展示，以方便技術開發人員理解交流，除此之外，需求定義過程中通常會出現的問題有內容失實、遺漏、含糊不清和前後描述不一致，需求攥寫人也著重標註類似業務需求點，以儘量減少或防止造成業務需求的二義性
3.1.4 需求評審
需求評審為需求五大階段的第四環節。關於需求評審，應著重關注如下幾個因素：
（一） 評審參與人員
原則上，需求評審應確保如下至少五方人員參與：
1.需求方：該需求提出人
2.開發方：該需求開發負責人
3.測試方：該需求測試人員
4.DBA方：相關DBA人員
5.運維方：相關運維人員
（二） 評審內容
評審內容，應從如下幾個方面進行：
1.需求方案可行性
應從需求業務價值可行性、技術可行性，運維可行性和成本可行性等諸多因素考慮
2.業務需求準確性
應從需求是否可行，需求是否遺漏，需求是否準確等方面評估
（三）評審記錄
需求評審階段，必須對評審過程和最終結果進行記錄，並歸檔
（四）評審修訂
評審過程，勢必會造成偏差，應對偏差進行糾正，並反覆校驗，從而形成最終需求文件
3.1.5 需求定稿
需求定稿為需求五大階段的最後環節。該環節將前四環節進行歸檔，並最終形成定稿《需求說明書》並歸檔，需求名建議格式：【需求負責人-類別-需求名稱-八位日期--版本-已評審】+檔案格式，如【wangjm-需求文件-支付系統設計一期-20211117-v1.0-已評審】.doc
3.2 架構維度
3.2.1 業務架構
業務架構作為技術方案的首要環節，若公司有業務架構師，應由業務架構師設計，否則由技術架構師設計。業務方案的好壞直接影響技術架構和技術選型的設計，因此在設計業務方案時，應重點考慮但不限於如下因素：
1.該業務的價值是什麼？直接利潤、間接利潤、流量、or其他？
2.定義業務類別，即該業務屬於0到1創新型業務，還是1.1到1複製型業務，或區域性創新型業務？
3.該業務是屬於核心業務，非核心業務還是公共業務？
4.該業務的領域邊界是什麼，該業務領域與其他業務領域的關聯關係是怎樣的，以及該業務對其他業務會產生怎樣的影響？
5.該業務的縱/橫向是怎樣的？
6.當前的業務現狀是怎樣的，深入挖掘過去，現在，以及未來可能的業務發展。
7.深入分析當前的業務痛點、業務瓶頸等。
3.2.2 業務架構評審
評估業務架構時，應重點考慮但不限於如下因素：
1.業務架構是否能準確描述《需求說明書》上的業務需求點？
2.業務架構是否存在遺漏《需求說明書》上的業務需求點？
3.業務架構是否結合公司技術棧，開發團隊、運維實際情況等因素綜合考慮？
4.業務架構是否準確體現核心業務和非核心業務？
5.業務架構是否對業務進行類別的高度抽象與剝離？
6.業務架構是否考慮公司未來業務的發展等諸多因素？
7.業務架構師在設計前和設計時，應反覆與需求方，產品經理和相關開發小組leader充分溝通，縮小偏差
8.評審結束後，必須形成業務架構方案，業務架構方案評估通過後，形成業務《業務架構方案》並歸檔，業務架構方案名格式參考：【業務架構師-類別-需求名稱-八位日期--版本-已評審】+檔案格式，如【wangjm-業務架構-支付系統設計一期-20211117-v1.0-已評審】.doc
3.2.3 技術架構
技術架構作為技術方案的第二環節。作為技術架構師，在進行技術架構前，必須深入研究《需求說明書》和《業務架構方案》，只有充分了解並掌握《需求說明書》和《業務架構方案》後，方可進行架構設計。
技術架構師在設計技術方案時，應重點考慮但不限於如下因素：
（一）掌握《需求說明書》和《業務架構方案》
作為技術架構師，必須深入研究《需求說明書》和《業務架構方案》，在研究中，遇到任何相關業務問題，應及時尋求相關業務人員、業務架構師等的幫助，避免對業務需求理解造成偏差，必須深入理解並掌握《需求說明書》和《業務架構方案》之後，方可設計《技術架構方案》。
（二）瞭解專案預算和專案週期
專案預算和專案週期，技術架構師在設計專案架構時，要充分考慮
（三）瞭解技術團隊素質
應充分考慮技術團隊素質，應著重考慮但不限於如下因素：
1.團隊技術棧
2.團隊技術人員梯隊
應充分考慮當前技術團隊梯隊，如高階專家、技術專家、高階技術和初中級技術等。
3.規劃參與專案開發的技術人員
充分了解《需求說明書》，《業務架構方案》，當前團隊技術棧和團隊技術人員梯隊後，就可以規劃實現需求的相關人員了，包括人數數量和人員級別，預計投入工作量等。
（四）確定技術方案
對（一）（二）（三）考慮充分後，即可進行技術方案的設計，在設計技術方案時，應重點考慮但不限於如下因素：
（1）開發語言選型
選擇什麼語言（或是混合語言，如java+php），應考慮諸多因素，如技術圈生態，團隊技術棧，成本，開發週期等，然後綜合權衡決定。
（2）前端框架
（3）後端框架
（4）快取技術
（5）資料庫技術
（6）中介軟體技術
（7）分散式技術
3.2.4 技術架構評審
作為技術架構師，在技術架構評審時，應重點評估如下要素。
1.當前公司技術現狀、瓶頸、以及未來發展
2.技術框架的成熟度、穩定性、可伸縮性、風險性等
3.所選型的技術生態，國內外現狀是怎樣的？
4.無論是servlet,ssh,ssm,microservice還是domain designer，邏輯架構要清晰，提供如下兩種架構模式參考：
模式一：servlet,ssh,ssm和microservice
說明：關於呼叫遠端服務問題，可在controller層，也可在service層，具體放在哪層呢？提供一個標準：若業務邏輯複雜，則放在service層；若業務邏輯簡單或基本沒任何業務邏輯，則可放在controller。當然，也可單獨將remote獨立成一個模組。
如下是我在支付寶總部工作時，SofaStack邏輯架構，供參考：
模式二：領域化
關於領域和微服務建設，可採參考六邊形模式：
六邊形模型：
邏輯架構：
3.2.5 方案評審參與人員
無論是《業務架構方案》還是《技術架構方案》，均需要評估，如下相關人員應參與方案的評估：
1.業務需求方
2.業務架構師、技術架構師
3.開發leader和開發相關人員
4.測試leader和測試相關人員
5.資料庫Leader和資料庫相關人員
6.運維leader和運維相關人員
3.2.6 技術選型參考
一、後端技術選型
對於新專案，技術選型應以如下技術選型為準；對於舊專案，迭代時，也應以如下技術選型為準。
1.後端框架：Spring,SpringBoot,SpringCloud
2.資料庫訪問技術：mybatis,hibernate(非特殊情況不用)
3.快取技術：redis
4.儲存技術：OSS
5.DB技術：MySql5.7
6.註冊中心：Eureaka,Zookeeper,Nacos(建議用)
7.配置中心：apollo
8.分散式技術：hmily,seata
9.鏈路追蹤:slueth
10.監控：cat
11.日誌：ELK，log4j2
12.管理框架：springadmin
13.許可權框架：OAuth2
14.分庫分表:MyCat(暫定)
15.開發工具：Idea 2018+，Navicat，RedisClient，VisualVM2.0.7，FinalShell
16.容器：Tomcat9+
17.jdk:1.8
18.mq:Rocketmq,Rabbitmq(非特殊情況不用)
19.壓測：jmeter
二、前端技術選型
1.基本前端技術：H5，CSS，JavaScript
2.框架：vue js(優先考慮)，Angular JS
三、運維技術選型
1.自動化釋出：Jenkins
2.jar包管理：Nexus
3.映象管理：Harbor
4.編譯工具：maven
5.壓力測試：jmeter
6.容器：docker,k8s
7.程式碼管理工具：git
7.負載均衡：F5(優先考慮)，Ngnix
3.3 開發維度
關於開發維度流程，對開發人員來說，還是比較清楚的，不多論述，補充一點：
在很多公司，其實是沒有自測和自測報環節的，開發人員開發結束後，就直接發給測試人員測試，關於是否建立該環節，不同公司，有不同取捨，根即實際情況來定，但一般具備一定規模的公司，原則上需要有的，
3.4 測試維度
嚴格來說，測試人員應包括：自動化測試、黑/白盒測試。
當前，行業存在這樣一種現象，IT文化不是很濃厚，或者從Donet轉型到java的一些公司，測試人員一般僅僅測試業務功能的準確性，而不深入到實際的程式碼、程式碼日誌、sql、資料準去性等，且公司的測試人員也不具備這樣的能力。但我們不能說這樣的測試就不好，要結合公司實際情況，我的觀點是，但凡涉及到核心業務、涉及到金額的，測試人員必須要深入到程式碼、程式碼日誌、sql、驗證資料準確性等，不能單純的點點頁面校驗業務邏輯。
無論公司測試類別是怎樣的，測試人員應準備測試用例，測試結束後，要有測試報告。
3.5 線前評審
所謂線前評審，指上線前的程式碼評審，評審內容大致如下：
3.5.1 程式碼規範性
Java後端開發規範，目前暫時參考阿里Java後端開發手冊，根據公司實際情況，逐步整合成屬於公司自己的規範。具體可參考如下網站：
https://github.com/alibaba/p3c
- 中文版:阿里巴巴Java開發手冊
- English Version: Alibaba Java Coding Guidelines
MySQL資料庫設計規範，目前暫時參考阿里MySQL設計規範，後期整合成屬於公司自己的規範。
3.5.2 原始碼管理規範
統一採用gitlab和git來管理程式碼，在進行迭代開發時，統一採用如下標準流程：
迭代分支和開發分支命名規則：
（1）迭代分支命名規則：專案名_feature_八位日期時間格式_需求編號
eg：order_feature_20210616_需求編號
（2）開發分支命名規則；專案名_開發人員姓名拼音_八位日期時間格式
eg：order_wangjm_20210616 _需求編號
說明：關於開發分支，要靈活，若是多人協作開發，則按照master=>featrue=>dev 流程；若只是個人開發，則可直接在迭代分支上開發，即master=>featrue
3.5.3 程式碼評審
對於核心業務，核心模組，尤其是涉及到使用者資產的功能，必須進行程式碼評審，架構師，專案leader，功能實際開發者和產品經理(需求方)參與程式碼評審，程式碼評審時，從如下幾個方面進行：
1.程式碼業務邏輯評估，主要包括是否存在功能缺失，業務準確性等
2.資料邏輯評估(SQL業務邏輯，Redis業務邏輯，Hubble業務邏輯，mq業務邏輯)
3.程式碼覆蓋率評估
4.日誌評估
5.try...catch... 評估
6.三板斧評估(可監控、可回滾和可灰度)。關於這點，是我之前在支付寶總部工作時，上線前的必須條件，一些公司資源可能還達不到該要求，可根據實際情況取捨。
3.6 運維維度
原則來說，釋出的職責應該由運維來做，但一般隨著公司業務的發展，規模的壯大，運維人手嚴重不夠，因此企業運維就推出了自動化釋出平臺，推出該平臺後，運維將釋出職責轉交給具體的業務開發部門，不再肩負釋出的職責，只為業務開發部門提供釋出過程中，遇到的平臺問題諮詢服務。
作為業務部門，在釋出時，注意幾個點：
1.釋出的順序。dev=>test=>uat=>gray=>prod
2.釋出的視窗，這個運維平臺統一控制的
3.回退機制
對於規模不是很大的公司，一般具備標準的dev=>test=>uat=>gray=>prod流程，但中間環境存在很多不規範，如可直接跳過uat發prod。支付寶的釋出流程是系統控制的，並且是一環扣一環的，只有前面環節過了，才能進入下一步環節，一般不能跨環節釋出，如dev不能直接到uat,必須dev=>test=>uat。
3.7 線上追蹤維度
1.釋出後的1小時內，需要驗證線上環境的正常性，如業務流準確性、資料準確性
2.驗證人員包括：開發、測試、產品經理、架構
3.若出現異常，及時回退，立刻止血。具有一定流量的系統，一般是禁止線上排查和線上修復問題的。
4.做好線上問題記錄，提供記錄格式，僅供參考：
4 資源管理
根據公司實際情況，資源管理可選方案還是蠻多的，當前比較受歡迎的資源管理工具主要為語雀和wiki。
提供如下資源類別劃分，僅供參考：
具體包括五大類別：技術文件，技術書籍，工具包，專案文件和產品文件。每個文件類別定義如下：
（1）技術文件：存放技術相關文件，如核心技術文件，技術攻關文件，團隊技術分享文件等
（2）技術書籍：存放技術類相關書籍
（3）工具包：存放IT公用的工具，分為mac和windows兩個版本
（4）專案文件：存放專案相關文件，具體專案又包含三類別文件：需求文件，開發文件和測試文件
（5）產品文件：存放產品相關文件， 此儲存空間使用物件為產品
大致目錄結構如下：
---資源管理
|--技術文件
|--技術書籍
|--工具包
|--mac工具包
|--win工具包
|--專案文件
|--專案名稱
|--需求文件
|--開發文件
|--測試文件
5 版權區
- 轉載部落格，必須註明部落格出處
- 博主網址：http://www.cnblogs.com/wangjiming/
- 如您有新想法，歡迎提出，郵箱：2098469527@qq.com
- 專業.NET之家技術QQ群：490539956
- 專業化Java之家QQ群：924412846
- 有問必答QQ群：2098469527
- 一對一技術輔導QQ：2098469527