這是近期在公司做的一次分享，這幾年的互聯(lián)網(wǎng)開發(fā)，算比較幸運，團隊一直踐行完善這套規(guī)范，沒有太多的阻礙，得益于公司整體氛圍，以及團隊對規(guī)范和寫文檔的不排斥，形成了良好的開發(fā)習慣

在這次分享后，發(fā)現(xiàn)好些大V也在談規(guī)范，寫文檔，估計是前段時間阿里又發(fā)布了開發(fā)手冊(華山版)，借鑒于一下，對一些細節(jié)做些補充，整理出來

整體流程

image

這個流程整體分為三個大階段：需求階段，開發(fā)階段，上線階段

需求階段

需求分析

這個階段主要是產(chǎn)品主導，收集痛點，歸集需求，制定目標，與架構(gòu)師討論架構(gòu)方案，與安全評估業(yè)務安全性

這兒可根據(jù)需求大小，具體行事，比如有些需求涉及方比較多，可能需要多次分組開會，不管是可行性分析，還是討論方案，不是一次就能完成的

需求評審

當產(chǎn)品已經(jīng)確定好這些方面，開始輸出PRD，與研發(fā)、測試一起評審需求

研發(fā)與測試需要理解需求，更要挑戰(zhàn)需求；

挑戰(zhàn)需求的目的不是砍需求，而是確認產(chǎn)品在需求分析階段的工作完備程度，比如遺留數(shù)據(jù)處理，對當前系統(tǒng)的影響層面，是否與當前系統(tǒng)重復度過高，業(yè)務價值

只有經(jīng)過充分討論，才能理解需求，完善需求，防止后期需求返工，某個細節(jié)沒有考慮，影響整體設計實現(xiàn)

這兒各個團隊實踐方式各不相同，比如有些是所有團隊成員都要參與，而有些只有具體參與開發(fā)測試參與

個人推崇所有成員都參與，這樣一是討論可以更充分，二是信息共享，防止因某成員個人原因，推遲需求進度

需求排期

對需求大家都達成了共識，此時就需要產(chǎn)品去需求確定優(yōu)先級，排期開發(fā)

確定開發(fā)周期，這兒也有很多具體做法，有些團隊是TL根據(jù)需求難易程序，變動大小，結(jié)合具體開發(fā)人員直接給出時間；有些團隊是具體開發(fā)自行評估時間

一般都是由開發(fā)人員自行評估，只要在合理范圍內(nèi)，都給予認同

當然在確定開發(fā)周期時，必須給出依據(jù)，依據(jù)來源于詳細設計，對于詳細設計文檔具體形式后面再談，至少開發(fā)人員知道需要增加多少接口，修改多少接口，大概邏輯；不然評估時長就是一個空談，造成整個項目的失控

開發(fā)階段

需求階段，從產(chǎn)品需求分析到開發(fā)人員評估出開發(fā)周期就已經(jīng)結(jié)束了；下一個階段進入開發(fā)階段

開發(fā)階段的進度，可以說八成是依賴第一階段的成果。編碼速度，實現(xiàn)手段只要是正常業(yè)務需求，一般都不會拖延時長

第一階段成果，對于開發(fā)人員來講，就是詳細設計文檔，文檔中有了相應流程圖，偽代碼，具體涉及接口也有了，此時就是一個代碼翻譯過程

此階段測試，需要輸出測試用例，進行冒煙，回歸測試；

自動化腳本完善

上線階段

測試完成之后，就準備上線了。

根據(jù)確定的上線日期，提前核對checklist

對一些需要提前的變更開始申請審批流程

配合監(jiān)控系統(tǒng)，需要對一些業(yè)務監(jiān)控項進行配置

產(chǎn)品開始對預發(fā)布環(huán)境進行驗收，驗收成功后；發(fā)布正式環(huán)境

上線收尾

收尾工作，這個階段，還有大量工作需要去做

1. 產(chǎn)品對需求進行總結(jié)，收集數(shù)據(jù)，分析效果，為下一期需求做準備
2. 開發(fā)需要對代碼進行整理，比如有些是為了灰度而生的無用代碼可以刪除

一個完整的需求開發(fā)流程到此結(jié)束，當然這只是理想狀態(tài)，還有很多不可預測問題，當然你也會吐槽，這是典型的瀑布開發(fā)模型，在敏捷大行其道時，是不是太守舊，太遲鈍，都2091年了，為什么還在玩這一套

理想是豐滿的，現(xiàn)實是骨感的。好比敏捷開發(fā)的參與者是一群開發(fā)經(jīng)驗豐富和才華橫溢的開發(fā)人員，而這樣的團隊有多少？強硬為了敏捷而敏捷會不會造成項目的不可控呢？

當然瀑布模型也有天生的缺點：每個階段的嚴格性，缺乏靈活性，而現(xiàn)實需求卻是經(jīng)常變化的

所以單純地選擇哪個模型是不可取的，只能根據(jù)實際情況出發(fā)，為業(yè)務提供最大化服務

細則規(guī)范

很多人都在要規(guī)范，但好像從沒思考過為什么需要規(guī)范？

《阿里巴巴java開發(fā)手冊》：手冊的愿景是碼出高效，碼出質(zhì)量

現(xiàn)代軟件架構(gòu)的復雜性需要協(xié)同開發(fā)完成，如何高效地協(xié)同呢？無規(guī)矩不成方圓，無規(guī)范難以協(xié)同，比如，制訂交通法規(guī)表面上是要限制行車權(quán)，實際上是保障公眾的人身安全，試想如果沒有限速，沒有紅綠燈，誰還敢上路行駛？對軟件來說，適當?shù)囊?guī)范和標準絕不是消滅代碼內(nèi)容的創(chuàng)造性、優(yōu)雅性，而是限制過度個性化，以一種普遍認可的統(tǒng)一方式一起做事，提升協(xié)作效率，降低溝通成本。 代碼的字里行間流淌的是軟件系統(tǒng)的血液，質(zhì)量的提
升是盡可能少踩坑，杜絕踩重復的坑，切實提升系統(tǒng)穩(wěn)定性，碼出質(zhì)量

從上段可以看出幾個目的

1. 高效協(xié)同，降低溝通成本；書同文，車同軌
2. 碼出質(zhì)量，降低故障率；
3. 工匠精神，追求卓越

評審會議

很多開發(fā)人員最怕開會，更要命的是很多會議是效率低下的。主要表現(xiàn)：

• 在沒有基本的認知共識就被拉去開會：這可能是主持者沒有提前知會，同步資料；以及沒有在線下達到一定共識就開會，結(jié)果會上各種討論;也可能是參會人員本身也沒有提前準備
• 會后沒有結(jié)論，或者結(jié)論不明確

所以在參與評審后，需要有一份輸出，文檔或者郵件，主要包括以下內(nèi)容

1. 評審日期與輪次
2. 業(yè)務需求的目的及價值描述
3. 參與人員及角色
4. 評審附件（PRD或郵件）
5. 評審結(jié)論
6. 評審遺留問題及跟進人

需求PRD

開發(fā)人員，最煩就是口頭需求，一句話需求，需要明文禁止

產(chǎn)品寫PRD，其實是個基本職業(yè)素養(yǎng)，結(jié)果現(xiàn)在還要明文規(guī)定，也算是個悲哀。

為什么要出PRD，其實不是開發(fā)人員故意為難產(chǎn)品，而是讓產(chǎn)品深刻理解需求，看這又是個怪事，產(chǎn)品還有不理解業(yè)務需求的，但就是常有產(chǎn)品自己都不理解業(yè)務，還一本正經(jīng)給研發(fā)提開發(fā)需求。

寫PRD的過程，就是梳理思考的過程，讓需求更明確，流程更完整，細節(jié)更透徹，這樣就不會出現(xiàn)提交給開發(fā)時，被開發(fā)一堆問題阻塞住。也可以防止在開發(fā)過程中，卻發(fā)現(xiàn)整個業(yè)務沒有形成閉環(huán)，造成返工，延時

那么開發(fā)如何拒絕口頭需求，一句話需求呢？

有時產(chǎn)品比較強勢，開發(fā)人員不好溝通，此時TL就應該對團隊明確規(guī)定，禁止產(chǎn)品此類行為，也要禁止開發(fā)接受此類需求，不能為了一時快，而整個工期慢

在接受到此類需求時，也需要一定的溝通技巧：

1. 多問幾個為什么：這比如你這個需求背后的目的和價值是什么？做了之后有什么預期的收益，為什么這么做就可以達到這個收益，你可以不直接問業(yè)務方，但是你也需要問自己，業(yè)務方的這個目標和做這個需求的路徑是否可以匹配得上，如果實現(xiàn)路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有做的必要性

2. 給出替代方案：經(jīng)過上面的步驟，其實你會發(fā)現(xiàn)你已經(jīng)過濾了一批無效的一句話需求，而有些需求可能是有一定的存在價值，但是可能業(yè)務方提到的點并不是有效的方案或者說成本太大的方案，這時你就需要思考替代方案，盡量通過現(xiàn)有方案或者小成本的方式來滿足業(yè)務方，間接的達到“拒絕”的效果

3. 不能直接說不，但可以有條件的說是：當你確定這個需求是ok的，但你確實暫時抽不出時間來搞定這個事情的時候，這時關(guān)鍵在于我們不能直接拒絕業(yè)務方，長此以往會影響到后續(xù)的合作關(guān)系，這種情況你可以說，這個需求我接受，但是我可能需要較長一些的緩沖時間或者砍一些需求(部分滿足)，又或者必須要按時上的話，不能保證項目的上線后的效果、質(zhì)量等，讓業(yè)務方來做部分的取舍

詳細設計文檔

首先禁止沒有文檔，直接修改代碼；這跟需求PRD類似，強迫開發(fā)人員思考需求，完善需求，胸中有丘壑，下筆自有神；不能在編碼過程，邊寫邊思考，不僅慢，還會漏洞百出

其實讓團隊寫文檔，也是個難事，推動很難，尤其管理者沒有引起重視，就更難。這是個怪事，不喜歡寫文檔，卻喜歡被返工，在開發(fā)過程因需求邏輯不完備而加班趕點，從上到下默認了這種怪事的正常化

為什么要寫設計文檔？

• 對自己，讓自己在動手寫代碼之前，幫助自己想得更清楚；
• 對項目，保證信息的一致性，保證項目的可控性，減少項目風險；
• 對團隊，確保知識的沉淀與傳承；

項目涉及多少個子系統(tǒng)，每個子系統(tǒng)涉及多少個模塊，模塊間的依賴關(guān)系如何，彼此要提供多少個接口，每個接口的參數(shù)如何，接口實現(xiàn)過程中上下游交互如何，核心邏輯用什么技術(shù)方案實現(xiàn)…

難道相關(guān)技術(shù)人都一清二楚么？很多自信的技術(shù)大神，“以為”懂了，但卻講不明白，其實就是不懂。很多“講得明白”，卻“寫不清楚”，其實就是沒懂透。把一個項目，一個技術(shù)問題，按照邏輯，用文字來一遍，才表示真正的想清楚了

這也是現(xiàn)在流行的，一解釋都懂，一問都不知，一討論就吵架

不再寫過多為什么要寫文檔了，一個習慣的改變不可能一下子就改變，這需要一個過程，也需要自我大膽嘗試

這兒給出一些實踐，詳細設計文檔寫些什么

其實一份詳細設計文檔，整體分為兩個部分：功能需求與非功能需求

1、需求信息

這兒包括需求背景，業(yè)務價值，預計上線時間，架構(gòu)設計wiki,產(chǎn)品及開發(fā)負責人，涉及到的服務，上下游服務

2、系統(tǒng)流程圖

闡述整體設計思路，涉及算法時，還需要詳細算法思路

包含上下游系統(tǒng)交互和數(shù)據(jù)流向，建議viso或者astash圖，要保存原圖文件以防后期維護修改

當然最好還要把設計思路背景說明一下，有多種方案時也羅列一下，因為系統(tǒng)現(xiàn)有狀況，進度安排，歷史數(shù)據(jù)等等原因，而選擇了當前方案，這樣自我分析完整，也免將來別人接手時可以追溯

3、接口列表

這兒列出所有涉及到的接口列表

標明新增加或者修改，以及接口詳細入?yún)ⅲ祷刂?/p>

一般會有api doc，或者類似swagger工具，接口變化時，也可以相應變化；如果沒有，那只能在文檔中詳細輸出

4、定時任務

有些任務不需要，有些任務可能有很多，需要指出任務功能，頻率

5、存儲變更

比如緩存，數(shù)據(jù)結(jié)構(gòu)，過期時間，預計數(shù)據(jù)增長

DB表設計，表修改，索引信息，數(shù)據(jù)增長量；有新的業(yè)務場景，一定要請DBA幫忙評估索引或者其他信息

6、配置組件

配置：比如配置中心，增加修改配置項，常為了灰度增加一些開關(guān)之類

組件：第三方依賴jar，不管是公司自研，還是外部開源；關(guān)注新特性給系統(tǒng)帶來的變化；這個對開發(fā)工作量很小，只需要修改版本號，但測試可能需要一些回歸量，尤其常出現(xiàn)的包沖突，造成日志不能正常輸出

7、非功能需求

接口在日常和大促時的調(diào)用量評估，是否有降級方案，灰度方案，能不能重試，需不需要壓測，這些都是圍繞服務治理做預案

這其實是個很大的模塊，很多已經(jīng)深入骨髓，變成常態(tài)，比如灰度，現(xiàn)在都是7*24小時在線服務的，前后版本的兼容必須考慮到

總結(jié)

當然這些并不是必須的，可以根據(jù)實際情況變通，有增有減；當然你也可能從不寫文檔，很多人喜歡看源碼，而不看文檔；其實這有些本末倒置，源碼只是告訴你了how,而文檔才解釋了what,why

架構(gòu)師是很多碼農(nóng)的追求，架構(gòu)師如何設計系統(tǒng)，如何讓開發(fā)人員去實施呢？當然是文檔，總不能直接給代碼吧