<cite id="9vvnb"></cite>
<cite id="9vvnb"></cite>
<var id="9vvnb"><strike id="9vvnb"></strike></var>
<menuitem id="9vvnb"><strike id="9vvnb"><listing id="9vvnb"></listing></strike></menuitem>
<cite id="9vvnb"><video id="9vvnb"></video></cite>
<cite id="9vvnb"></cite>
<cite id="9vvnb"><video id="9vvnb"></video></cite>
<var id="9vvnb"></var>
<cite id="9vvnb"></cite><cite id="9vvnb"><span id="9vvnb"></span></cite>
<cite id="9vvnb"><span id="9vvnb"><menuitem id="9vvnb"></menuitem></span></cite>
Fork me on GitHub

關于研發規范化的一些實踐和思考

除了老板之外,我想大多數人是討厭規則的,因為它束縛了我們的自由。然而,無論是個人,還是組織,規則卻是發展中必不可少的環節,雖然我們很難看出規則的直接價值。

研發類任務,更是一類嚴謹的工作,它不僅需要嚴謹的邏輯思維能力,更需要一個完善的研發規范流程。對于程序員的我們,其實我們心里是比較討厭規則的,在我們心里,只要把需求完成,上線就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

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.m3gworks.com/wangjiming/
  •    如您有新想法,歡迎提出,郵箱:2098469527@qq.com
  •   專業.NET之家技術QQ群:490539956
  •   專業化Java之家QQ群:924412846
  •   有問必答QQ群:2098469527
  •   一對一技術輔導QQ:2098469527
posted @ 2021-11-18 15:34  Alan_beijing  閱讀(2461)  評論(22編輯  收藏  舉報
黄色网站在现免费看_黄色网站在线18P_黄色网站在线播放