除了老闆之外，我想大多數人是讨厭規則的，因為它束縛了我們的自由。然而，無論是個人，還是組織，規則卻是發展中必不可少的環節，雖然我們很難看出規則的直接價值。
研發類任務，更是一類嚴謹的工作，它不僅需要嚴謹的邏輯思維能力，更需要一個完善的研發規範流程。對于程式員的我們，其實我們心裡是比較讨厭規則的，在我們心裡，隻要把需求完成，上線就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/
- 如您有新想法，歡迎提出，郵箱：[email protected]
- 專業.NET之家技術QQ群：490539956
- 專業化Java之家QQ群：924412846
- 有問必答QQ群：2098469527
- 一對一技術輔導QQ：2098469527