這是近期在公司做的一次分享魂贬，這幾年的互聯(lián)網(wǎng)開發(fā)，算比較幸運裙顽，團隊一直踐行完善這套規(guī)范付燥，沒有太多的阻礙，得益于公司整體氛圍愈犹，以及團隊對規(guī)范和寫文檔的不排斥键科，形成了良好的開發(fā)習(xí)慣
在這次分享后，發(fā)現(xiàn)好些大V也在談規(guī)范，寫文檔勋颖，估計是前段時間阿里又發(fā)布了開發(fā)手冊(華山版)嗦嗡，借鑒于一下，對一些細節(jié)做些補充饭玲，整理出來
整體流程
這個流程整體分為三個大階段：需求階段侥祭，開發(fā)階段，上線階段
需求階段
需求分析
這個階段主要是產(chǎn)品主導(dǎo)咱枉，收集痛點卑硫，歸集需求徒恋，制定目標(biāo)蚕断，與架構(gòu)師討論架構(gòu)方案，與安全評估業(yè)務(wù)安全性
這兒可根據(jù)需求大小入挣，具體行事亿乳，比如有些需求涉及方比較多，可能需要多次分組開會径筏，不管是可行性分析葛假，還是討論方案，不是一次就能完成的
需求評審
當(dāng)產(chǎn)品已經(jīng)確定好這些方面滋恬，開始輸出PRD聊训，與研發(fā)、測試一起評審需求
研發(fā)與測試需要理解需求恢氯，更要挑戰(zhàn)需求带斑；
挑戰(zhàn)需求的目的不是砍需求，而是確認(rèn)產(chǎn)品在需求分析階段的工作完備程度勋拟，比如遺留數(shù)據(jù)處理勋磕，對當(dāng)前系統(tǒng)的影響層面，是否與當(dāng)前系統(tǒng)重復(fù)度過高敢靡，業(yè)務(wù)價值
只有經(jīng)過充分討論挂滓，才能理解需求，完善需求啸胧，防止后期需求返工赶站，某個細節(jié)沒有考慮，影響整體設(shè)計實現(xiàn)
這兒各個團隊實踐方式各不相同纺念，比如有些是所有團隊成員都要參與亲怠，而有些只有具體參與開發(fā)測試參與
個人推崇所有成員都參與，這樣一是討論可以更充分柠辞，二是信息共享团秽，防止因某成員個人原因，推遲需求進度
需求排期
對需求大家都達成了共識，此時就需要產(chǎn)品去需求確定優(yōu)先級习勤，排期開發(fā)
確定開發(fā)周期踪栋，這兒也有很多具體做法，有些團隊是TL根據(jù)需求難易程序图毕，變動大小夷都，結(jié)合具體開發(fā)人員直接給出時間；有些團隊是具體開發(fā)自行評估時間
一般都是由開發(fā)人員自行評估予颤，只要在合理范圍內(nèi)囤官，都給予認(rèn)同
當(dāng)然在確定開發(fā)周期時，必須給出依據(jù)蛤虐，依據(jù)來源于詳細設(shè)計党饮，對于詳細設(shè)計文檔具體形式后面再談，至少開發(fā)人員知道需要增加多少接口驳庭，修改多少接口刑顺，大概邏輯；不然評估時長就是一個空談饲常，造成整個項目的失控
開發(fā)階段
需求階段蹲堂，從產(chǎn)品需求分析到開發(fā)人員評估出開發(fā)周期就已經(jīng)結(jié)束了；下一個階段進入開發(fā)階段
開發(fā)階段的進度贝淤，可以說八成是依賴第一階段的成果柒竞。編碼速度，實現(xiàn)手段只要是正常業(yè)務(wù)需求播聪，一般都不會拖延時長
第一階段成果朽基，對于開發(fā)人員來講，就是詳細設(shè)計文檔犬耻，文檔中有了相應(yīng)流程圖踩晶，偽代碼，具體涉及接口也有了枕磁，此時就是一個代碼翻譯過程
此階段測試渡蜻，需要輸出測試用例，進行冒煙计济，回歸測試茸苇；
自動化腳本完善
上線階段
測試完成之后，就準(zhǔn)備上線了沦寂。
根據(jù)確定的上線日期学密，提前核對checklist
對一些需要提前的變更開始申請審批流程
配合監(jiān)控系統(tǒng)，需要對一些業(yè)務(wù)監(jiān)控項進行配置
產(chǎn)品開始對預(yù)發(fā)布環(huán)境進行驗收传藏，驗收成功后腻暮；發(fā)布正式環(huán)境
上線收尾
收尾工作彤守，這個階段，還有大量工作需要去做
- 產(chǎn)品對需求進行總結(jié)哭靖，收集數(shù)據(jù)具垫，分析效果，為下一期需求做準(zhǔn)備
- 開發(fā)需要對代碼進行整理试幽，比如有些是為了灰度而生的無用代碼可以刪除
一個完整的需求開發(fā)流程到此結(jié)束筝蚕，當(dāng)然這只是理想狀態(tài)，還有很多不可預(yù)測問題铺坞，當(dāng)然你也會吐槽起宽，這是典型的瀑布開發(fā)模型，在敏捷大行其道時济榨，是不是太守舊坯沪，太遲鈍，都2091年了腿短，為什么還在玩這一套
理想是豐滿的屏箍，現(xiàn)實是骨感的绘梦。好比敏捷開發(fā)的參與者是一群開發(fā)經(jīng)驗豐富和才華橫溢的開發(fā)人員橘忱，而這樣的團隊有多少？強硬為了敏捷而敏捷會不會造成項目的不可控呢卸奉？
當(dāng)然瀑布模型也有天生的缺點：每個階段的嚴(yán)格性钝诚，缺乏靈活性，而現(xiàn)實需求卻是經(jīng)常變化的
所以單純地選擇哪個模型是不可取的榄棵，只能根據(jù)實際情況出發(fā)凝颇，為業(yè)務(wù)提供最大化服務(wù)
細則規(guī)范
很多人都在要規(guī)范，但好像從沒思考過為什么需要規(guī)范疹鳄？
《阿里巴巴java開發(fā)手冊》：手冊的愿景是碼出高效拧略，碼出質(zhì)量
現(xiàn)代軟件架構(gòu)的復(fù)雜性需要協(xié)同開發(fā)完成，如何高效地協(xié)同呢瘪弓？無規(guī)矩不成方圓垫蛆，無規(guī)范難以協(xié)同，比如腺怯，制訂交通法規(guī)表面上是要限制行車權(quán)袱饭，實際上是保障公眾的人身安全，試想如果沒有限速呛占，沒有紅綠燈虑乖，誰還敢上路行駛？對軟件來說晾虑，適當(dāng)?shù)囊?guī)范和標(biāo)準(zhǔn)絕不是消滅代碼內(nèi)容的創(chuàng)造性疹味、優(yōu)雅性仅叫，而是限制過度個性化，以一種普遍認(rèn)可的統(tǒng)一方式一起做事糙捺，提升協(xié)作效率惑芭，降低溝通成本。 代碼的字里行間流淌的是軟件系統(tǒng)的血液继找，質(zhì)量的提
升是盡可能少踩坑遂跟，杜絕踩重復(fù)的坑，切實提升系統(tǒng)穩(wěn)定性婴渡，碼出質(zhì)量
從上段可以看出幾個目的
- 高效協(xié)同幻锁，降低溝通成本；書同文边臼，車同軌
- 碼出質(zhì)量哄尔，降低故障率；
- 工匠精神柠并，追求卓越
評審會議
很多開發(fā)人員最怕開會岭接，更要命的是很多會議是效率低下的。主要表現(xiàn)：
- 在沒有基本的認(rèn)知共識就被拉去開會：這可能是主持者沒有提前知會臼予，同步資料鸣戴；以及沒有在線下達到一定共識就開會，結(jié)果會上各種討論;也可能是參會人員本身也沒有提前準(zhǔn)備
- 會后沒有結(jié)論粘拾，或者結(jié)論不明確
所以在參與評審后窄锅，需要有一份輸出，文檔或者郵件缰雇，主要包括以下內(nèi)容
- 評審日期與輪次
- 業(yè)務(wù)需求的目的及價值描述
- 參與人員及角色
- 評審附件（PRD或郵件）
- 評審結(jié)論
- 評審遺留問題及跟進人
需求PRD
開發(fā)人員入偷，最煩就是口頭需求，一句話需求械哟，需要明文禁止
產(chǎn)品寫PRD疏之，其實是個基本職業(yè)素養(yǎng)，結(jié)果現(xiàn)在還要明文規(guī)定暇咆，也算是個悲哀锋爪。
為什么要出PRD，其實不是開發(fā)人員故意為難產(chǎn)品糯崎，而是讓產(chǎn)品深刻理解需求几缭，看這又是個怪事，產(chǎn)品還有不理解業(yè)務(wù)需求的沃呢，但就是常有產(chǎn)品自己都不理解業(yè)務(wù)年栓，還一本正經(jīng)給研發(fā)提開發(fā)需求。
寫PRD的過程薄霜，就是梳理思考的過程某抓，讓需求更明確纸兔，流程更完整，細節(jié)更透徹否副，這樣就不會出現(xiàn)提交給開發(fā)時汉矿，被開發(fā)一堆問題阻塞住。也可以防止在開發(fā)過程中备禀，卻發(fā)現(xiàn)整個業(yè)務(wù)沒有形成閉環(huán)洲拇，造成返工，延時
那么開發(fā)如何拒絕口頭需求曲尸，一句話需求呢赋续？
有時產(chǎn)品比較強勢，開發(fā)人員不好溝通另患，此時TL就應(yīng)該對團隊明確規(guī)定纽乱，禁止產(chǎn)品此類行為，也要禁止開發(fā)接受此類需求昆箕，不能為了一時快鸦列，而整個工期慢
在接受到此類需求時，也需要一定的溝通技巧：
多問幾個為什么：這比如你這個需求背后的目的和價值是什么鹏倘？做了之后有什么預(yù)期的收益薯嗤，為什么這么做就可以達到這個收益，你可以不直接問業(yè)務(wù)方第股，但是你也需要問自己应民，業(yè)務(wù)方的這個目標(biāo)和做這個需求的路徑是否可以匹配得上话原，如果實現(xiàn)路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有做的必要性
給出替代方案：經(jīng)過上面的步驟夕吻，其實你會發(fā)現(xiàn)你已經(jīng)過濾了一批無效的一句話需求，而有些需求可能是有一定的存在價值繁仁，但是可能業(yè)務(wù)方提到的點并不是有效的方案或者說成本太大的方案涉馅，這時你就需要思考替代方案，盡量通過現(xiàn)有方案或者小成本的方式來滿足業(yè)務(wù)方黄虱，間接的達到“拒絕”的效果
不能直接說不稚矿，但可以有條件的說是：當(dāng)你確定這個需求是ok的，但你確實暫時抽不出時間來搞定這個事情的時候捻浦，這時關(guān)鍵在于我們不能直接拒絕業(yè)務(wù)方晤揣，長此以往會影響到后續(xù)的合作關(guān)系，這種情況你可以說朱灿，這個需求我接受昧识，但是我可能需要較長一些的緩沖時間或者砍一些需求(部分滿足)，又或者必須要按時上的話盗扒，不能保證項目的上線后的效果跪楞、質(zhì)量等缀去，讓業(yè)務(wù)方來做部分的取舍
詳細設(shè)計文檔
首先禁止沒有文檔，直接修改代碼甸祭；這跟需求PRD類似缕碎，強迫開發(fā)人員思考需求，完善需求池户，胸中有丘壑咏雌，下筆自有神；不能在編碼過程校焦，邊寫邊思考处嫌，不僅慢，還會漏洞百出
其實讓團隊寫文檔斟湃，也是個難事熏迹，推動很難，尤其管理者沒有引起重視凝赛，就更難注暗。這是個怪事，不喜歡寫文檔墓猎，卻喜歡被返工捆昏，在開發(fā)過程因需求邏輯不完備而加班趕點，從上到下默認(rèn)了這種怪事的正潮姓矗化
為什么要寫設(shè)計文檔骗卜？
- 對自己，讓自己在動手寫代碼之前左胞，幫助自己想得更清楚寇仓；
- 對項目，保證信息的一致性烤宙，保證項目的可控性遍烦，減少項目風(fēng)險；
- 對團隊躺枕，確保知識的沉淀與傳承服猪；
項目涉及多少個子系統(tǒng)，每個子系統(tǒng)涉及多少個模塊拐云，模塊間的依賴關(guān)系如何罢猪，彼此要提供多少個接口，每個接口的參數(shù)如何叉瘩，接口實現(xiàn)過程中上下游交互如何膳帕，核心邏輯用什么技術(shù)方案實現(xiàn)…
難道相關(guān)技術(shù)人都一清二楚么？很多自信的技術(shù)大神房揭，“以為”懂了备闲，但卻講不明白晌端，其實就是不懂。很多“講得明白”恬砂，卻“寫不清楚”咧纠，其實就是沒懂透。把一個項目泻骤，一個技術(shù)問題漆羔，按照邏輯，用文字來一遍狱掂，才表示真正的想清楚了
這也是現(xiàn)在流行的演痒，一解釋都懂，一問都不知趋惨，一討論就吵架
不再寫過多為什么要寫文檔了鸟顺，一個習(xí)慣的改變不可能一下子就改變，這需要一個過程器虾，也需要自我大膽嘗試
這兒給出一些實踐讯嫂，詳細設(shè)計文檔寫些什么
其實一份詳細設(shè)計文檔，整體分為兩個部分：功能需求與非功能需求
1兆沙、需求信息
這兒包括需求背景欧芽，業(yè)務(wù)價值，預(yù)計上線時間葛圃，架構(gòu)設(shè)計wiki,產(chǎn)品及開發(fā)負責(zé)人千扔，涉及到的服務(wù)，上下游服務(wù)
2库正、系統(tǒng)流程圖
闡述整體設(shè)計思路曲楚，涉及算法時，還需要詳細算法思路
包含上下游系統(tǒng)交互和數(shù)據(jù)流向诀诊，建議viso或者astash圖洞渤，要保存原圖文件以防后期維護修改
當(dāng)然最好還要把設(shè)計思路背景說明一下，有多種方案時也羅列一下属瓣，因為系統(tǒng)現(xiàn)有狀況，進度安排讯柔，歷史數(shù)據(jù)等等原因抡蛙，而選擇了當(dāng)前方案，這樣自我分析完整魂迄，也免將來別人接手時可以追溯
3粗截、接口列表
這兒列出所有涉及到的接口列表
標(biāo)明新增加或者修改，以及接口詳細入?yún)⒌肪妫祷刂?/p>
一般會有api doc熊昌，或者類似swagger工具绽榛，接口變化時，也可以相應(yīng)變化婿屹；如果沒有灭美，那只能在文檔中詳細輸出
4、定時任務(wù)
有些任務(wù)不需要昂利，有些任務(wù)可能有很多届腐，需要指出任務(wù)功能，頻率
5蜂奸、存儲變更
比如緩存犁苏，數(shù)據(jù)結(jié)構(gòu)，過期時間扩所，預(yù)計數(shù)據(jù)增長
DB表設(shè)計围详，表修改，索引信息祖屏，數(shù)據(jù)增長量短曾；有新的業(yè)務(wù)場景，一定要請DBA幫忙評估索引或者其他信息
6赐劣、配置組件
配置：比如配置中心嫉拐，增加修改配置項骗灶，常為了灰度增加一些開關(guān)之類
組件：第三方依賴jar掸屡，不管是公司自研抢埋，還是外部開源湾揽；關(guān)注新特性給系統(tǒng)帶來的變化凌埂；這個對開發(fā)工作量很小卒落，只需要修改版本號瓣颅，但測試可能需要一些回歸量弧岳，尤其常出現(xiàn)的包沖突化撕，造成日志不能正常輸出
7几晤、非功能需求
接口在日常和大促時的調(diào)用量評估，是否有降級方案植阴，灰度方案蟹瘾，能不能重試，需不需要壓測掠手，這些都是圍繞服務(wù)治理做預(yù)案
這其實是個很大的模塊憾朴，很多已經(jīng)深入骨髓，變成常態(tài)喷鸽，比如灰度众雷，現(xiàn)在都是7*24小時在線服務(wù)的，前后版本的兼容必須考慮到
總結(jié)
當(dāng)然這些并不是必須的，可以根據(jù)實際情況變通砾省，有增有減鸡岗；當(dāng)然你也可能從不寫文檔，很多人喜歡看源碼编兄，而不看文檔轩性；其實這有些本末倒置，源碼只是告訴你了how,而文檔才解釋了what,why
架構(gòu)師是很多碼農(nóng)的追求翻诉，架構(gòu)師如何設(shè)計系統(tǒng)炮姨，如何讓開發(fā)人員去實施呢？當(dāng)然是文檔碰煌，總不能直接給代碼吧
