面試官:你了解規(guī)范的開發(fā)流程嗎?
作者 |?訢亮
來源 |?新亮筆記
概述
這篇文章分享開發(fā)流程規(guī)范，目的是提高產(chǎn)品質(zhì)量，優(yōu)化開發(fā)流程，供大家參考。
規(guī)范是死的，人是活的，希望自己定的規(guī)范，不要被打臉。
接下來從以上六個階段進行逐一拆解。
1 需求評審
作為技術人員肯定都參加過需求評審會，不知道有沒有遇到這樣的情況？
- 產(chǎn)品經(jīng)理按照 PRD 文檔讀一遍，參會人員無動于衷。
- 產(chǎn)品經(jīng)理剛講了一個需求點，參會人員就產(chǎn)生了激烈的討論，都在證明自己是對的。
- 參會人員對需求的目標不明確，對需求點進行發(fā)散思維討論，最終偏離方向。
遇到以上問題，肯定是在參加需求評審之前未做充分準備，那么問題來了，需要提前準備什么？
評審前
不要聽產(chǎn)品同學說，該需求是大老板跟進的、非常重要、非常緊急之類的，就問產(chǎn)品三個問題：
- 解決了什么問題？
- 提升了什么指標？
- 有什么商業(yè)價值？
這三個問題搞清楚了，再進行評審。
產(chǎn)品經(jīng)理發(fā)出 原型 和 PRD 初稿后，開發(fā)人員要有 1-2 天時間（具體時間根據(jù)項目大小而定），熟悉文檔，有任何疑問可以反饋給開發(fā)經(jīng)理，由開發(fā)經(jīng)理統(tǒng)一收集再反饋給產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理逐一進行答疑。
熟悉完文檔后，開發(fā)人員和開發(fā)經(jīng)理需要一起確定：
- 技術選型（前端/后端框架、日志中間件、消息中間件、數(shù)據(jù)庫...）
- 技術架構（組件與組件之間如何協(xié)同工作，如何部署）
- 技術難點預知（明確存在的技術難點，并確定解決方案）
- 性能瓶頸預知（明確可能存在性能瓶頸的地方，并確定應對措施）
- 上下游系統(tǒng)交互（明確在流程中的哪個位置，約定接口文檔提供時間、接口聯(lián)調(diào)時間）
- 功能模塊劃分（任務拆分和分配）
技術方案確定后，需要輸出技術設計文檔，包括：總體設計、概要設計、詳細設計、接口設計 等。
評審中
開發(fā)人員必須參加，有需求不明確的地方當場提出，同時開發(fā)人員也需要思考產(chǎn)品需求是否合理，可適當提出自己的產(chǎn)品意見。
一般評審至少有兩次（初稿和終稿）。
評審后
評審后，如有需更新技術文檔的請及時進行更新。
開發(fā)經(jīng)理首先需要考慮團隊現(xiàn)有的資源及項目的優(yōu)先級，然后根據(jù)技術設計文檔進行評估排期。
排期模板如下：
2 技術評審
評審前
開發(fā)人員一定要重視技術設計！
開發(fā)人員一定要重視技術設計！
開發(fā)人員一定要重視技術設計！
重要事情說三遍！
技術評審主要評審什么？
系統(tǒng)關系圖、模塊關系圖、流程圖的設計，畫圖工具根據(jù)自己愛好即可。接口設計，需要考慮接口的 兼容性、擴展性、參數(shù)命名遵守 參數(shù)命名規(guī)范 等。數(shù)據(jù)庫設計，需要遵守 數(shù)據(jù)庫設計規(guī)范，并記錄 數(shù)據(jù)表變更文檔。詳細設計，需要考慮公共類、公共方法、方法定義 遵守 項目框架目錄規(guī)范。
評審中
開發(fā)人員和開發(fā)經(jīng)理必須參加，涉及到總體設計和概要設計時，需要邀請 架構師 參與，涉及到數(shù)據(jù)庫調(diào)整時，需要邀請 DBA 參與。
一般評審至少有兩次（初稿和終稿）。
評審后
評審后，如有需更新排期文檔的請及時進行更新。
排期確定后，通過郵件方式進行回復排期，使用標準化的 回復排期郵件模板。
按部就班，按計劃行事。
3 需求開發(fā)
編碼
開發(fā)人員編碼過程中，需要遵守團隊的 編碼規(guī)范，同時嚴格按照設計文檔中的技術方案執(zhí)行，除了保證代碼邏輯的正確性外，還需要考慮代碼封裝性、可維護性、可擴展性，當編碼階段發(fā)現(xiàn)技術方案需要調(diào)整時，需要及時通知開發(fā)經(jīng)理，經(jīng)過同意后才能實施，涉及到引入新框架和新技術，也需要提前通知開發(fā)經(jīng)理。
代碼審查
開發(fā)人員需要控制代碼提交的頻次和粒度，每次代碼提交之后 24 小時內(nèi)，需要主動聯(lián)系代碼審查人完成檢查，開發(fā)經(jīng)理負責檢查是否執(zhí)行到位。
代碼審查主要審查什么？
- 規(guī)范性檢查（是否符合代碼規(guī)范、提交備注規(guī)范等）
- 健壯性檢查（是否陷入死循環(huán)、資源未釋放等）
- 安全性檢查（是否存在SQL注入、XSS、SSRF、CSRF、越權、文件上傳等）
- 性能檢查（是否存在未加緩存頻繁連接DB，是否需要連接池）
聯(lián)調(diào)
開發(fā)人員積極主動地推動聯(lián)調(diào)工作，如果遇到阻礙及時通知技術經(jīng)理進行協(xié)調(diào)。
自測
聯(lián)調(diào)完畢后，開發(fā)人員需要同時完成自測，并將標準化的 自測報告 發(fā)給測試團隊。
對于有性能要求的項目，需要開發(fā)人員進行性能測試，并出具標準化的 性能測試報告。
提測
自測完畢后，通過郵件方式進行提測申請，使用標準化的 申請?zhí)釡y郵件模板。
開發(fā)人員根據(jù)公司運維提供的發(fā)布方式，進行部署到測試環(huán)境。
4 跟進測試
測試用例評審
開發(fā)人員必須參加，避免出現(xiàn)測試與開發(fā)對需求理解不一致的情況。
Bug 修復
開發(fā)人員及時關注 Bug 列表，快速修復迭代發(fā)布，如果測試進度存在延期風險，需要及時通知開發(fā)經(jīng)理。
5 跟進上線
開發(fā)人員首先確認 Bug 全部關閉，同時產(chǎn)品人員在測試環(huán)境驗收通過，然后需要主動推動相關團隊理清上線依賴和上線順序，同時確定回滾預案，最后根據(jù)公司運維提供的發(fā)布方式，進行部署到線上環(huán)境。
線上環(huán)境部署完成后，通過郵件方式進行通知產(chǎn)品人員和測試人員，使用標準化的 上線完畢郵件模板，同時積極推動測試人員和產(chǎn)品人員完成線上驗證，線上出現(xiàn)問題后第一時間通知開發(fā)經(jīng)理。
6 線上問題復盤
需求在測試環(huán)境和正式環(huán)境，均未測試出 Bug，上線一段時候后出現(xiàn) Bug，這種問題用什么制度約束？
出現(xiàn)問題后開發(fā)人員及時修復，修復完了就完事了。僅僅做到這些還遠遠不夠。
建議使用如下模板進行復盤。
小結
大家可以數(shù)一數(shù)上面使用到了多少規(guī)范，這時有朋友會說了，這規(guī)范也太多了吧，這和工廠工人有什么區(qū)別，我們程序員是有創(chuàng)造性的，我們喜歡前沿性、挑戰(zhàn)性的工作，我們放蕩不羈愛自由...
針對這個問題，首先我不否認開發(fā)人員是有創(chuàng)造性的，但并不是所有的程序員都有創(chuàng)造性，在現(xiàn)實工作場景中大部分程序員不是做創(chuàng)造性工作的，也沒必要做創(chuàng)造性工作，所以必須按照規(guī)范流程執(zhí)行。
團隊管理和團隊之間合作，必須要有規(guī)范，并嚴格執(zhí)行。
就到這吧，以上供參考。