我前段時(shí)間帶了個(gè)新項(xiàng)目團(tuán)隊(duì)里三位剛?cè)肼毜耐聨缀跬瑫r(shí)問(wèn)了我一個(gè)問(wèn)題“咱們這個(gè)項(xiàng)目的開(kāi)發(fā)流程到底是什么先干嘛后干嘛要是需求改了怎么辦”那一刻我才意識(shí)到很多科班出身、甚至已經(jīng)寫(xiě)過(guò)不少代碼的人對(duì)“軟件工程”這四個(gè)字的理解其實(shí)還停留在“寫(xiě)代碼”這一個(gè)環(huán)節(jié)上。軟件工程和寫(xiě)代碼之間的關(guān)系有點(diǎn)像建房和砌磚。打地基、立框架、走水電、驗(yàn)收裝修每一步都有嚴(yán)格的先后邏輯和驗(yàn)收標(biāo)準(zhǔn)。你一個(gè)人自己住可以隨性一點(diǎn)但一旦要交付給用戶(hù)、要團(tuán)隊(duì)協(xié)作、要長(zhǎng)期維護(hù)就必須有章法。這篇東西就是圍繞軟件開(kāi)發(fā)大致流程做一個(gè)系統(tǒng)梳理從需求到上線再到維護(hù)把每個(gè)環(huán)節(jié)的核心任務(wù)、常用方法、實(shí)操套路和踩坑經(jīng)驗(yàn)都講透。不管是正在做課程設(shè)計(jì)的學(xué)生、準(zhǔn)備畢業(yè)設(shè)計(jì)的同學(xué)還是剛?cè)胄械男氯藨?yīng)該都能從這里找到可以直接參考的東西。適用范圍我也提前說(shuō)明白我講的是通用流程Web應(yīng)用、App、嵌入式比如lvgl這類(lèi)GUI項(xiàng)目、甚至部分硬件聯(lián)調(diào)項(xiàng)目都適用。具體到某個(gè)行業(yè)可能會(huì)裁剪但主干邏輯不會(huì)變。1. 內(nèi)容整體設(shè)計(jì)與思路拆解我一直覺(jué)得把“軟件開(kāi)發(fā)流程”講清楚最重要的不是列舉步驟而是講清楚步驟背后的邏輯?；ヂ?lián)網(wǎng)上關(guān)于軟件工程的資料汗牛充棟但大多數(shù)要么是教材式的羅列要么是某個(gè)具體工具的使用教程。真正從項(xiàng)目推進(jìn)視角出發(fā)、把每一步“為什么這么做”講透的內(nèi)容反而不多。1.1 核心需求解析流程的四個(gè)價(jià)值先說(shuō)結(jié)論規(guī)范化流程不是為了增加工作量它解決的是四個(gè)核心問(wèn)題?？深A(yù)測(cè)性。沒(méi)有流程的項(xiàng)目進(jìn)度全憑感覺(jué)。有流程之后每個(gè)階段有明確的起點(diǎn)和終點(diǎn)你能說(shuō)出來(lái)項(xiàng)目目前處于什么狀態(tài)、還差多少工作量、風(fēng)險(xiǎn)在哪里。做過(guò)項(xiàng)目的人都知道項(xiàng)目延期不是最可怕的最可怕的是沒(méi)人知道延期了?？勺匪菪?。軟件交付之后出問(wèn)題需要能回答“這個(gè)功能當(dāng)初是誰(shuí)定的為什么這么做當(dāng)時(shí)的考慮是什么”流程中每個(gè)階段的產(chǎn)物——需求文檔、設(shè)計(jì)文檔、測(cè)試用例——實(shí)際上是項(xiàng)目的記憶。沒(méi)有這些記憶維護(hù)階段就是兩眼一抹黑?？煞止ば?。軟件開(kāi)發(fā)幾乎沒(méi)有單人能獨(dú)立完成的大型項(xiàng)目。流程定義了協(xié)作的接口產(chǎn)品經(jīng)理產(chǎn)出需求文檔架構(gòu)師產(chǎn)出設(shè)計(jì)文檔開(kāi)發(fā)照著設(shè)計(jì)編碼測(cè)試基于需求驗(yàn)證。大家各司其職銜接處有契約協(xié)作才不會(huì)亂?？沈?yàn)證性。流程的每個(gè)階段都有交付物和驗(yàn)收標(biāo)準(zhǔn)。需求要評(píng)審、設(shè)計(jì)要評(píng)審、代碼要審查、測(cè)試要出報(bào)告。每一道關(guān)卡都是質(zhì)量閘門(mén)把問(wèn)題攔截在早期。做過(guò)開(kāi)發(fā)的人都知道需求階段的錯(cuò)誤拖到測(cè)試階段才暴露修復(fù)成本可能放大幾十倍。1.2 全流程全景從需求到維護(hù)的八個(gè)月臺(tái)我用一個(gè)比較宏觀的圖景來(lái)框定整個(gè)流程。不同公司、不同團(tuán)隊(duì)會(huì)對(duì)這個(gè)過(guò)程做裁剪和調(diào)整但主干框架相對(duì)穩(wěn)定階段核心任務(wù)主要交付物參與角色需求分析搞清楚要做什么需求規(guī)格說(shuō)明書(shū)、原型圖產(chǎn)品經(jīng)理、業(yè)務(wù)方概要設(shè)計(jì)決定怎么做架構(gòu)設(shè)計(jì)文檔、技術(shù)選型方案架構(gòu)師、技術(shù)負(fù)責(zé)人詳細(xì)設(shè)計(jì)細(xì)化模塊實(shí)現(xiàn)詳細(xì)設(shè)計(jì)文檔、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔開(kāi)發(fā)工程師編碼實(shí)現(xiàn)把設(shè)計(jì)變成代碼源代碼、單元測(cè)試開(kāi)發(fā)工程師測(cè)試驗(yàn)證驗(yàn)證做對(duì)了測(cè)試用例、測(cè)試報(bào)告、缺陷列表測(cè)試工程師部署發(fā)布讓用戶(hù)用得上發(fā)布計(jì)劃、部署腳本、運(yùn)維手冊(cè)運(yùn)維、DevOps工程師運(yùn)維監(jiān)控保證正常用監(jiān)控報(bào)表、日志、應(yīng)急預(yù)案運(yùn)維工程師項(xiàng)目收尾總結(jié)經(jīng)驗(yàn)教訓(xùn)項(xiàng)目總結(jié)報(bào)告、經(jīng)驗(yàn)池更新項(xiàng)目經(jīng)理、全員用旅行來(lái)類(lèi)比的話需求分析是確定“去哪兒”設(shè)計(jì)和編碼是解決“怎么去”測(cè)試是“檢查有沒(méi)有走錯(cuò)路”發(fā)布就是“到目的地”。很多人覺(jué)得軟件開(kāi)發(fā)的樂(lè)趣在于編碼但真正決定項(xiàng)目成敗的往往是編碼前后的那些環(huán)節(jié)。2. 需求分析階段決定項(xiàng)目生死的第一道關(guān)口接觸過(guò)大量項(xiàng)目后我愈發(fā)確認(rèn)一個(gè)判斷大部分失敗項(xiàng)目的根源不在技術(shù)而在需求階段出了問(wèn)題。要么需求沒(méi)搞清楚就動(dòng)手要么需求經(jīng)常變導(dǎo)致返工。這里說(shuō)的“需求”不是用戶(hù)隨口說(shuō)的一句話而是經(jīng)過(guò)調(diào)研、分析、驗(yàn)證后形成的完整定義。2.1 用戶(hù)需求與技術(shù)需求的正確理解方式這個(gè)詞組十個(gè)做軟件的人里面有八個(gè)掛在嘴邊但真能說(shuō)清楚的可能連一半都不到。我分享一個(gè)行業(yè)內(nèi)公認(rèn)的理解框架分成兩層。第一層叫用戶(hù)需求。用戶(hù)用大白話說(shuō)出來(lái)的“我想要什么”。比如“我想讓客戶(hù)在手機(jī)上就能看到訂單進(jìn)度”。這類(lèi)需求的特點(diǎn)是原生態(tài)、充滿(mǎn)個(gè)人視角描述的是“愿望”而非“方案”。第二層叫技術(shù)需求。作為軟件開(kāi)發(fā)人員把用戶(hù)需求轉(zhuǎn)化為可落地的功能定義。同樣是“讓客戶(hù)在手機(jī)上看到訂單進(jìn)度”技術(shù)需求可能要拆成用戶(hù)登錄模塊、訂單狀態(tài)同步邏輯、消息推送服務(wù)、進(jìn)度頁(yè)面交互設(shè)計(jì)、異常狀態(tài)處理……每一塊都要有清晰的定義。這里面最忌諱的是把用戶(hù)需求直接當(dāng)技術(shù)需求用?！坝脩?hù)想看訂單進(jìn)度”這句話如果直接丟給開(kāi)發(fā)十個(gè)開(kāi)發(fā)能做出十種不同的東西。區(qū)別就在于有人做出來(lái)的只是在訂單列表后面加一列狀態(tài)文字有人做出來(lái)的是帶推送提醒、時(shí)間線動(dòng)畫(huà)、異常狀態(tài)引導(dǎo)的完整體驗(yàn)。差別不在技術(shù)能力而在對(duì)需求的理解深度。2.2 需求調(diào)研的四個(gè)常用方法做需求不是坐在工位上憑空想象需要走出去搜集信息。我整理了一下最常用的是四種方法。用戶(hù)訪談是一對(duì)一直接聊好處是能得到深度信息壞處是耗時(shí)間和精力而且樣本量小的時(shí)候容易被個(gè)別用戶(hù)的極端觀點(diǎn)帶偏。問(wèn)卷調(diào)查能快速收集大量用戶(hù)反饋適合驗(yàn)證某個(gè)假設(shè)但問(wèn)卷設(shè)計(jì)本身有門(mén)檻問(wèn)題問(wèn)得不好得到的數(shù)據(jù)參考價(jià)值有限。競(jìng)品分析是看別人怎么做的省時(shí)省力但容易把團(tuán)隊(duì)帶進(jìn)“抄襲”的思維定式忽略自身產(chǎn)品定位。數(shù)據(jù)分析最適合已有產(chǎn)品做迭代優(yōu)化通過(guò)埋點(diǎn)數(shù)據(jù)、用戶(hù)行為日志發(fā)現(xiàn)真實(shí)使用問(wèn)題但前提是得有存量數(shù)據(jù)和成熟的數(shù)據(jù)平臺(tái)。我的實(shí)操建議是組合使用前期用訪談和競(jìng)品分析探索方向中期用問(wèn)卷驗(yàn)證假設(shè)后期在已有版本上用數(shù)據(jù)持續(xù)驅(qū)動(dòng)迭代。別指望一種方法解決所有問(wèn)題。2.3 需求文檔應(yīng)該寫(xiě)什么需求規(guī)格說(shuō)明書(shū)是需求階段的標(biāo)志性交付物。剛工作那會(huì)兒我也覺(jué)得寫(xiě)文檔是浪費(fèi)時(shí)間直到某次被產(chǎn)品經(jīng)理拉去跟一個(gè)三年前的舊模塊做維護(hù)看著那段沒(méi)人能講清楚當(dāng)初為什么這么寫(xiě)的代碼我才明白文檔的價(jià)值。一份能用的需求文檔我認(rèn)為至少包含五個(gè)部分項(xiàng)目背景與目標(biāo)說(shuō)清楚為什么做、做成什么樣算成功用戶(hù)角色與使用場(chǎng)景明確目標(biāo)用戶(hù)是誰(shuí)在什么情境下用功能需求清單按優(yōu)先級(jí)必須做、應(yīng)該做、可以不做列出功能點(diǎn)和驗(yàn)收標(biāo)準(zhǔn)非功能需求包括性能指標(biāo)、安全要求、兼容性要求、可用性等業(yè)務(wù)規(guī)則與約束包括特殊的業(yè)務(wù)邏輯、合規(guī)要求、技術(shù)限制等。寫(xiě)需求文檔有個(gè)我自己特別注重的習(xí)慣凡是能用數(shù)字表達(dá)的要求絕不用模糊詞匯?！绊?yè)面加載速度要快”這種描述等于沒(méi)寫(xiě)“首屏加載時(shí)間不超過(guò)3秒”才是合格的需求。還有一個(gè)容易被忽略的是優(yōu)先級(jí)所有功能都標(biāo)成“必須做”等于沒(méi)有標(biāo)一定要逼著業(yè)務(wù)方排出先后。2.4 需求變更的處理邏輯需求變更是軟件開(kāi)發(fā)中不可避免的。大到業(yè)務(wù)方向調(diào)整小到按鈕文案修改每天都在發(fā)生。處理需求變更的關(guān)鍵不在于“堵”而在于建立有序的變更管理機(jī)制。我比較推崇的是建立變更控制委員會(huì)哪怕是小型項(xiàng)目也要有一個(gè)指定的負(fù)責(zé)人來(lái)把關(guān)變更。任何需求變更都要走流程提交變更申請(qǐng)、評(píng)估影響范圍、確認(rèn)優(yōu)先級(jí)、排期實(shí)施。有人覺(jué)得這是小題大做但經(jīng)歷過(guò)上線前三天需求大改導(dǎo)致項(xiàng)目延期的事情就會(huì)理解這個(gè)機(jī)制的價(jià)值。對(duì)于學(xué)生做課程設(shè)計(jì)或者畢業(yè)設(shè)計(jì)我也提個(gè)醒指導(dǎo)老師給出的需求最好一開(kāi)始就問(wèn)清楚哪些是必須實(shí)現(xiàn)的、哪些是可以擴(kuò)展的按“基礎(chǔ)功能保證完成、加分項(xiàng)有余力再上”的思路安排時(shí)間避免中后期因?yàn)樽非笸昝缹?dǎo)致整盤(pán)皆輸。3. 概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)階段把“做什么”變成“怎么做”需求明確了之后接下來(lái)就是決定軟件長(zhǎng)什么樣的設(shè)計(jì)階段。設(shè)計(jì)階段在整個(gè)軟件開(kāi)發(fā)流程中是最容易被新人低估的一環(huán)。我見(jiàn)過(guò)太多人拿到需求就開(kāi)寫(xiě)代碼寫(xiě)到一半發(fā)現(xiàn)整體結(jié)構(gòu)撐不住擴(kuò)展推倒重來(lái)的例子比比皆是。3.1 概要設(shè)計(jì)的核心內(nèi)容架構(gòu)與技術(shù)選型概要設(shè)計(jì)要回答的核心問(wèn)題是“系統(tǒng)整體的骨架怎么搭”。這里面的關(guān)鍵決策包括技術(shù)棧選型、系統(tǒng)架構(gòu)模式、模塊劃分、數(shù)據(jù)庫(kù)選型、關(guān)鍵業(yè)務(wù)流程設(shè)計(jì)。以技術(shù)棧選型為例我現(xiàn)在看到一個(gè)項(xiàng)目第一反應(yīng)是看它的技術(shù)棧是什么、為什么這么選。像題目相關(guān)的Python軟件工程選擇Python做后端可能是因?yàn)閳F(tuán)隊(duì)熟悉Python、生態(tài)豐富、快速迭代能力強(qiáng)也可能是因?yàn)樾枰玫絇ython在AI/數(shù)據(jù)處理方面的能力。選型的核心邏輯是“合適”不是“流行”。從熱詞里看到lvgl 開(kāi)發(fā)流程這個(gè)也值得說(shuō)一下。LVGL是一個(gè)嵌入式GUI庫(kù)在嵌入式設(shè)備上做圖形界面開(kāi)發(fā)。它的開(kāi)發(fā)流程和通用軟件開(kāi)發(fā)流程類(lèi)似但有自己的特點(diǎn)要提前確認(rèn)硬件平臺(tái)的算力、內(nèi)存、顯示分辨率再根據(jù)硬件資源裁剪LVGL的組件和配置。這類(lèi)項(xiàng)目的概要設(shè)計(jì)階段硬件選型甚至比軟件技術(shù)選型更前置。我在之前的項(xiàng)目里遇到過(guò)在資源極緊張的MCU上硬上復(fù)雜動(dòng)畫(huà)效果的情況最后是把動(dòng)畫(huà)frame rate從60fps降到30fps、去掉陰影和漸變效果才勉強(qiáng)跑起來(lái)。如果在設(shè)計(jì)階段就做好資源評(píng)估這些返工完全可以避免。架構(gòu)設(shè)計(jì)方面經(jīng)典的包括單體架構(gòu)、微服務(wù)架構(gòu)、分層架構(gòu)、事件驅(qū)動(dòng)架構(gòu)等。每一種架構(gòu)都有自己的適用場(chǎng)景單體架構(gòu)適合業(yè)務(wù)相對(duì)簡(jiǎn)單、團(tuán)隊(duì)規(guī)模小的項(xiàng)目微服務(wù)適合大型復(fù)雜系統(tǒng)需要獨(dú)立擴(kuò)展、獨(dú)立部署的場(chǎng)景但也帶來(lái)分布式事務(wù)、服務(wù)治理等額外復(fù)雜度分層架構(gòu)最通用把系統(tǒng)分成表現(xiàn)層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問(wèn)層職責(zé)清晰、易維護(hù)。3.2 詳細(xì)設(shè)計(jì)的關(guān)鍵產(chǎn)出概要設(shè)計(jì)決定“系統(tǒng)大概長(zhǎng)什么樣”詳細(xì)設(shè)計(jì)則要說(shuō)明“每個(gè)模塊具體怎么實(shí)現(xiàn)”。這個(gè)階段的主要產(chǎn)出包括模塊內(nèi)部邏輯設(shè)計(jì)每個(gè)模塊的類(lèi)、函數(shù)、接口怎么定義狀態(tài)怎么流轉(zhuǎn)數(shù)據(jù)庫(kù)詳細(xì)設(shè)計(jì)表結(jié)構(gòu)、索引設(shè)計(jì)、字段約束、數(shù)據(jù)字典接口詳細(xì)設(shè)計(jì)接口路徑、請(qǐng)求參數(shù)、響應(yīng)格式、異常碼定義關(guān)鍵技術(shù)難點(diǎn)分析比如高并發(fā)場(chǎng)景的緩存策略、分布式環(huán)境下的數(shù)據(jù)一致性方案這塊很核心的一點(diǎn)是明確每個(gè)模塊的對(duì)外接口。接口是團(tuán)隊(duì)協(xié)作的契約模塊A和模塊B能不能并行開(kāi)發(fā)、能不能獨(dú)立測(cè)試就看接口定義得夠不夠清晰。我見(jiàn)過(guò)不少團(tuán)隊(duì)前期不重視接口設(shè)計(jì)到了聯(lián)調(diào)階段兩個(gè)開(kāi)發(fā)面對(duì)面“對(duì)齊參數(shù)”效率極低還容易埋下隱患。從熱詞里看到floyed算法類(lèi)似的算法軟件工程這是一個(gè)很有意思的切入點(diǎn)。Floyd-Warshall算法解決的是“最短路徑”問(wèn)題在軟件工程中如果你發(fā)現(xiàn)某個(gè)核心功能涉及到類(lèi)似的路徑優(yōu)化、動(dòng)態(tài)規(guī)劃問(wèn)題那么在詳細(xì)設(shè)計(jì)階段就應(yīng)該明確算法選型與實(shí)現(xiàn)思路。算法設(shè)計(jì)不僅要保證邏輯正確還要分析時(shí)間復(fù)雜度和空間復(fù)雜度是否滿(mǎn)足業(yè)務(wù)的性能要求。比如地圖導(dǎo)航項(xiàng)目里如果道路節(jié)點(diǎn)數(shù)量達(dá)到百萬(wàn)級(jí)別Floyd算法的城市立方復(fù)雜度就完全不可行必須考慮Dijkstra或A*等更適配的算法。這就是詳細(xì)設(shè)計(jì)階段要解決的關(guān)鍵問(wèn)題。3.3 設(shè)計(jì)驗(yàn)證與評(píng)審的正確姿勢(shì)設(shè)計(jì)文檔寫(xiě)完之后不能直接拿去編碼需要經(jīng)過(guò)評(píng)審。評(píng)審的目的是提前發(fā)現(xiàn)設(shè)計(jì)中的缺陷和問(wèn)題這個(gè)環(huán)節(jié)的投入產(chǎn)出比是很高的。做評(píng)審的時(shí)候有幾個(gè)實(shí)用技巧。第一評(píng)審前必須提前發(fā)材料讓大家有充分的閱讀時(shí)間。直接開(kāi)會(huì)現(xiàn)場(chǎng)看文檔基本等于白評(píng)。第二評(píng)審要關(guān)注風(fēng)險(xiǎn)點(diǎn)而不是糾結(jié)細(xì)節(jié)功能把重點(diǎn)放在架構(gòu)合理性、性能隱患、擴(kuò)展性、安全性這些設(shè)計(jì)層面的大問(wèn)題上。第三評(píng)審結(jié)論要有記錄、有負(fù)責(zé)人、有期限?！鞍l(fā)現(xiàn)問(wèn)題-確認(rèn)修改-驗(yàn)證閉環(huán)”才是完整的評(píng)審流程。我個(gè)人的經(jīng)驗(yàn)是在評(píng)審時(shí)專(zhuān)門(mén)安排一個(gè)“挑戰(zhàn)者”角色或者評(píng)委輪流挑毛病負(fù)責(zé)從反面去質(zhì)疑設(shè)計(jì)方案的假設(shè)。很多設(shè)計(jì)問(wèn)題在正向邏輯中根本看不出來(lái)但只要有人問(wèn)一句“這個(gè)方案在什么情況下會(huì)失效”往往就能找到盲區(qū)。4. 編碼實(shí)現(xiàn)階段讓設(shè)計(jì)變成可運(yùn)行的軟件設(shè)計(jì)階段完成進(jìn)入到大多數(shù)開(kāi)發(fā)人員最熟悉的編碼階段。雖然編碼是這個(gè)階段的主旋律但它不光是悶頭敲代碼那么單純。一個(gè)規(guī)范的編碼過(guò)程涉及環(huán)境的搭建、代碼規(guī)范的執(zhí)行、編碼自測(cè)、代碼審查和版本管理等多個(gè)維度。4.1 開(kāi)發(fā)環(huán)境的標(biāo)準(zhǔn)化配置開(kāi)發(fā)環(huán)境不一致導(dǎo)致的“在我機(jī)器上明明能跑”的經(jīng)典悲劇相信不少人都經(jīng)歷過(guò)。規(guī)范的做法是把開(kāi)發(fā)環(huán)境做成可復(fù)現(xiàn)的標(biāo)準(zhǔn)配置。用Docker之類(lèi)的容器化技術(shù)來(lái)統(tǒng)一開(kāi)發(fā)環(huán)境把我推給所有團(tuán)隊(duì)成員新成員加入后拉下來(lái)就能直接開(kāi)發(fā)整個(gè)過(guò)程不超過(guò)十分鐘。相比之前那種手動(dòng)裝數(shù)據(jù)庫(kù)、配置中間件、改環(huán)境變量的老辦法效率和一致性都提升了不少。用Python項(xiàng)目來(lái)舉例說(shuō)明一下規(guī)范的做法。常規(guī)的Python項(xiàng)目環(huán)境管理應(yīng)該做到# 通過(guò)虛擬環(huán)境隔離項(xiàng)目依賴(lài) python -m venv venv source venv/bin/activate # Windows下為 venv\Scripts\activate # 依賴(lài)鎖定確?？蓮?fù)現(xiàn) pip freeze requirements.txt # 或者使用更現(xiàn)代的Poetry管理工具 poetry init poetry add flask requests poetry lock很多新手常犯的錯(cuò)誤是直接在全局環(huán)境里pip install包過(guò)段時(shí)間包越裝越亂版本沖突頻繁。用虛擬環(huán)境把每個(gè)項(xiàng)目的依賴(lài)隔離起來(lái)是Python開(kāi)發(fā)最基本的工程化學(xué)術(shù)素養(yǎng)。4.2 編碼規(guī)范與代碼審查編碼規(guī)范這個(gè)話題聽(tīng)著老生常談但真踩過(guò)坑才知道它的價(jià)值。團(tuán)隊(duì)里如果每個(gè)人風(fēng)格迥異命名方式五花八門(mén)代碼可讀性會(huì)大打折扣。有人用駝峰有人用下劃線有人喜歡簡(jiǎn)寫(xiě)變量名有人一個(gè)函數(shù)寫(xiě)兩百行——這種代碼看著就頭疼更別提維護(hù)了。我在團(tuán)隊(duì)里推編碼規(guī)范的經(jīng)驗(yàn)是不要貪大求全先定幾條硬性規(guī)則能自動(dòng)檢查的都通過(guò)工具解決。比如Python就用flake8加black做靜態(tài)檢查和格式化JavaScript就用ESLint加Prettier這些東西配置好后不需要人肉執(zhí)行提交代碼時(shí)自動(dòng)化檢查就能攔截問(wèn)題。代碼審查Code Review的價(jià)值比很多團(tuán)隊(duì)想象的要大。審查的過(guò)程不僅是發(fā)現(xiàn)代碼缺陷更是一種知識(shí)傳遞和技術(shù)對(duì)齊。我做Code Review時(shí)重點(diǎn)關(guān)注四個(gè)方面邏輯正確性是否存在潛在的邏輯錯(cuò)誤或者邊界條件遺漏可讀性代碼能不能讓其他人不看注釋也能理解安全性有沒(méi)有SQL注入、敏感信息泄露、數(shù)據(jù)越權(quán)之類(lèi)的風(fēng)險(xiǎn)性能隱患是否在循環(huán)里查詢(xún)數(shù)據(jù)庫(kù)有沒(méi)有無(wú)謂的對(duì)象創(chuàng)建Code Review要控制節(jié)奏一次審查的代碼量太大容易走形式。我一般控制在200到400行代碼一次新人代碼會(huì)審得更仔細(xì)一些目的不在挑毛病而是幫他把好的工程習(xí)慣培養(yǎng)起來(lái)。4.3 Git版本管理的團(tuán)隊(duì)協(xié)作戰(zhàn)版本管理在現(xiàn)代軟件開(kāi)發(fā)中是無(wú)論如何都繞不開(kāi)的一環(huán)Git更是事實(shí)標(biāo)準(zhǔn)。對(duì)于個(gè)人項(xiàng)目Git可能只需要掌握add、commit、push、pull這些基礎(chǔ)命令就夠了。但團(tuán)隊(duì)協(xié)作場(chǎng)景下Git的分支管理策略直接關(guān)系到開(kāi)發(fā)流程是否順暢。我推薦一種比較經(jīng)典的Git Flow變體供大家參考分支類(lèi)型命名規(guī)則用途master/mainmaster生產(chǎn)發(fā)布分支始終保持可部署狀態(tài)developdevelop日常開(kāi)發(fā)集成分支所有功能最終合入這里featurefeature/xxx-功能描述每個(gè)功能一個(gè)獨(dú)立分支開(kāi)發(fā)完成后合入developreleaserelease/版本號(hào)發(fā)布前的準(zhǔn)備分支做最后的回歸測(cè)試和缺陷修復(fù)hotfixhotfix/版本號(hào)生產(chǎn)環(huán)境緊急缺陷修復(fù)分支用feature分支做開(kāi)發(fā)的好處很明顯每個(gè)功能獨(dú)立開(kāi)發(fā)互不干擾即使某個(gè)功能開(kāi)發(fā)失敗也不會(huì)影響主線。提交信息講究一個(gè)原則按照“類(lèi)型(scope): 描述”的規(guī)范來(lái)寫(xiě)feat、fix、docs這些前綴能讓人一眼看出提交意圖配合issue或者任務(wù)編號(hào)也能把代碼變更和需求關(guān)聯(lián)起來(lái)。4.4 單元測(cè)試不是選做題很多自學(xué)的開(kāi)發(fā)者沒(méi)有寫(xiě)單元測(cè)試的習(xí)慣覺(jué)得那是測(cè)試人員的事或者覺(jué)得寫(xiě)測(cè)試?yán)速M(fèi)時(shí)間。但在我看過(guò)的所有軟件工程流程里單元測(cè)試恰恰是編碼階段質(zhì)量保障的關(guān)鍵一環(huán)。單元測(cè)試的價(jià)值可以從兩個(gè)方面來(lái)理解。一方面它驗(yàn)證了函數(shù)或模塊的局部邏輯正確性能讓開(kāi)發(fā)者提交代碼之前就發(fā)現(xiàn)自己引入的問(wèn)題。另一個(gè)方面可能更重要——它在控制“回歸風(fēng)險(xiǎn)”。當(dāng)你修改一個(gè)功能的時(shí)候存量測(cè)試用例可以立刻告訴你哪些原有功能被破壞了。沒(méi)有測(cè)試保護(hù)的代碼就像在拆一顆不知道什么時(shí)候會(huì)爆的定時(shí)炸彈。以Python為例用pytest寫(xiě)單元測(cè)試是很直觀的# 待測(cè)試模塊 calculator.py def add(a, b): return a b def divide(a, b): if b 0: raise ValueError(除數(shù)不能為零) return a / b # 測(cè)試文件 test_calculator.py import pytest from calculator import add, divide def test_add(): assert add(2, 3) 5 assert add(-1, 1) 0 def test_divide_normal(): assert divide(10, 2) 5 def test_divide_by_zero(): with pytest.raises(ValueError): divide(10, 0)編寫(xiě)測(cè)試用例時(shí)要重點(diǎn)覆蓋三類(lèi)場(chǎng)景正常場(chǎng)景、邊界場(chǎng)景、異常場(chǎng)景。比如處理日期格式的函數(shù)要測(cè)正常的2024-01-15也要測(cè)2月30日這種非法輸入還要測(cè)空值、NULL值。測(cè)試的目的不是證明代碼沒(méi)問(wèn)題而是把可能出問(wèn)題的角落提前照亮。5. 測(cè)試階段與部署發(fā)布確保質(zhì)量交付可用版本編碼完成并不代表軟件可以交付。從編碼完成到用戶(hù)真正用上中間有測(cè)試和部署這兩個(gè)重要階段。很多小型團(tuán)隊(duì)為追求速度把這兩個(gè)環(huán)節(jié)壓縮到幾乎不存在往往是項(xiàng)目后期缺陷集中爆發(fā)的原因。5.1 測(cè)試方法論從單元測(cè)試到端到端測(cè)試軟件開(kāi)發(fā)過(guò)程中涉及的測(cè)試層級(jí)像是一座金字塔。最底層是單元測(cè)試關(guān)注單個(gè)函數(shù)或模塊運(yùn)行快、定位準(zhǔn)往上一層是集成測(cè)試驗(yàn)證模塊之間的交互是否正確比如API調(diào)用是否能正確處理返回值再往上是系統(tǒng)測(cè)試把整個(gè)系統(tǒng)當(dāng)作一個(gè)整體來(lái)驗(yàn)證關(guān)注功能是否齊全、性能是否達(dá)標(biāo)最頂層是驗(yàn)收測(cè)試從用戶(hù)視角確認(rèn)交付物是否滿(mǎn)足最初的需求通常由業(yè)務(wù)方或產(chǎn)品經(jīng)理參與。這套體系在嵌入式GUI開(kāi)發(fā)里同樣適用只是形式上有變化。用lvgl開(kāi)發(fā)嵌入式界面時(shí)單元測(cè)試可以是控件邏輯的純函數(shù)測(cè)試集成測(cè)試要結(jié)合模擬器驗(yàn)證控件間的消息傳遞系統(tǒng)測(cè)試就要在真機(jī)上跑。每一層都有價(jià)值不能跳級(jí)。那學(xué)校里的軟件工程課程設(shè)計(jì)怎么做測(cè)試方案我的建議是根據(jù)項(xiàng)目規(guī)模調(diào)整測(cè)試層級(jí)。一個(gè)課程設(shè)計(jì)級(jí)別的項(xiàng)目至少要寫(xiě)關(guān)鍵的單元測(cè)試覆蓋核心業(yè)務(wù)邏輯做一次完整的端到端手工測(cè)試把主要功能路徑走一遍記錄測(cè)試結(jié)果。這比將來(lái)在簡(jiǎn)歷上寫(xiě)一句“負(fù)責(zé)過(guò)測(cè)試”要有說(shuō)服力得多。5.2 編寫(xiě)高效的測(cè)試用例測(cè)試用例的質(zhì)量直接決定測(cè)試效果。一個(gè)高質(zhì)量的測(cè)試用例通常包括編號(hào)、測(cè)試名稱(chēng)、前置條件、測(cè)試步驟、輸入數(shù)據(jù)、預(yù)期結(jié)果、實(shí)際結(jié)果、優(yōu)先級(jí)等要素。以最常見(jiàn)的登錄功能為例測(cè)試用例至少要覆蓋以下幾種情況正確的用戶(hù)名和密碼驗(yàn)證能成功登錄正確的用戶(hù)名和錯(cuò)誤的密碼驗(yàn)證有錯(cuò)誤提示且不會(huì)登錄不存在的用戶(hù)名驗(yàn)證有統(tǒng)一的錯(cuò)誤提示用戶(hù)名密碼為空驗(yàn)證有輸入校驗(yàn)攔截錯(cuò)誤密碼連續(xù)輸入多次驗(yàn)證有鎖定或驗(yàn)證碼機(jī)制SQL注入類(lèi)特殊輸入驗(yàn)證不會(huì)繞過(guò)鑒權(quán)覆蓋率是衡量測(cè)試用例是否全面的核心指標(biāo)但也不必追求100%行覆蓋率。對(duì)業(yè)務(wù)核心邏輯、復(fù)雜算法、用戶(hù)高頻路徑的覆蓋遠(yuǎn)比覆蓋率數(shù)字重要。很多項(xiàng)目測(cè)試資源有限合理的做法是把資源集中投向風(fēng)險(xiǎn)最高的部分。5.3 持續(xù)集成/持續(xù)部署的作用持續(xù)集成和持續(xù)部署在正規(guī)的開(kāi)發(fā)流程中已經(jīng)非常普及。持續(xù)集成要求開(kāi)發(fā)人員頻繁地將代碼合并到主干分支每次合并都自動(dòng)觸發(fā)構(gòu)建和測(cè)試盡早暴露集成問(wèn)題。持續(xù)部署則是在持續(xù)集成的基礎(chǔ)上通過(guò)自動(dòng)化方式將驗(yàn)證通過(guò)的版本部署到環(huán)境中。以GitHub Actions為例一個(gè)簡(jiǎn)單的Python項(xiàng)目CI配置可以寫(xiě)成本配置name: Python CI on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest - name: Run tests run: pytest tests/ -v - name: Lint check run: | pip install flake8 flake8 src/這套配置的意義在于每一次代碼提交推到遠(yuǎn)程倉(cāng)庫(kù)云端就會(huì)自動(dòng)執(zhí)行一遍測(cè)試和靜態(tài)檢查。發(fā)現(xiàn)問(wèn)題的成本被壓縮到最低修正問(wèn)題的速度也被大大加快。5.4 部署發(fā)布與上線回滾方案部署發(fā)布是整個(gè)開(kāi)發(fā)流程中對(duì)“安全感”要求最高的環(huán)節(jié)。就算是經(jīng)驗(yàn)豐富的團(tuán)隊(duì)發(fā)布到生產(chǎn)環(huán)境前也還是要做足準(zhǔn)備。發(fā)布清單通常包含這些內(nèi)容回滾方案、數(shù)據(jù)庫(kù)遷移腳本、配置變更說(shuō)明、監(jiān)控告警配置、操作手冊(cè)?；貪L方案是最容易被忽視又最要命的一項(xiàng)。沒(méi)有回滾方案的發(fā)布就像高空走鋼絲不帶安全繩。即使做了充分測(cè)試生產(chǎn)環(huán)境的復(fù)雜性和不可預(yù)測(cè)性也可能導(dǎo)致發(fā)布后出現(xiàn)嚴(yán)重問(wèn)題。這時(shí)候最快的止損動(dòng)作就是把版本回退到上一個(gè)可用版本。我經(jīng)歷過(guò)的發(fā)布失敗案例里最常見(jiàn)的原因有幾個(gè)數(shù)據(jù)庫(kù)結(jié)構(gòu)變更沒(méi)考慮到向下兼容、配置項(xiàng)遺漏導(dǎo)致新代碼讀取不到參數(shù)、并發(fā)量超過(guò)壓測(cè)預(yù)期導(dǎo)致服務(wù)雪崩。后來(lái)的應(yīng)對(duì)策略是所有數(shù)據(jù)庫(kù)變更遵循“先加后減”的兼容原則配置項(xiàng)變更提前一天上線并做好灰度每次發(fā)布前進(jìn)行一次全鏈路壓測(cè)。這些經(jīng)驗(yàn)也算得上是拿真金白銀換來(lái)的教訓(xùn)了。6. 從項(xiàng)目管理的視角看流程落地與避坑上面講的更多是技術(shù)環(huán)節(jié)但軟件開(kāi)發(fā)流程在實(shí)際落地中還嚴(yán)重受項(xiàng)目管理水平的影響。同樣的團(tuán)隊(duì)同樣的技術(shù)棧不同的項(xiàng)目管理方式結(jié)果可能會(huì)是天壤之別。6.1 開(kāi)發(fā)流程中的經(jīng)典方法論對(duì)比軟件工程領(lǐng)域的發(fā)展本質(zhì)上就是一部流程方法論不斷進(jìn)化迭代的歷史。這里我不做教科書(shū)式的羅列只挑幾種對(duì)實(shí)踐影響比較大的模型說(shuō)清楚。瀑布模型是最經(jīng)典的流程模型強(qiáng)調(diào)順序執(zhí)行、階段明確需求、設(shè)計(jì)、編碼、測(cè)試、維護(hù)逐層推進(jìn)。優(yōu)點(diǎn)在于階段交付物清晰利于管理和控制缺點(diǎn)是不能很好地響應(yīng)需求變化適合需求穩(wěn)定的項(xiàng)目。敏捷開(kāi)發(fā)是當(dāng)下最主流的開(kāi)發(fā)模式強(qiáng)調(diào)迭代開(kāi)發(fā)、持續(xù)交付、擁抱變化。Scrum是敏捷的代表實(shí)踐之一通過(guò)短周期的沖刺迭代不斷產(chǎn)出可用軟件。它的優(yōu)勢(shì)是響應(yīng)快、客戶(hù)參與度高但對(duì)團(tuán)隊(duì)自律性要求比較高。如果你去看那句“l(fā)vgl 開(kāi)發(fā)流程”很多GUI項(xiàng)目團(tuán)隊(duì)也是用敏捷迭代的方式在推進(jìn)——每個(gè)迭代完成幾個(gè)控件交互效果最后整合集成。統(tǒng)一軟件開(kāi)發(fā)過(guò)程是另一種方法論用一句話概括就是“用例驅(qū)動(dòng)、以架構(gòu)為中心、迭代和增量”。它將軟件開(kāi)發(fā)分為初始、細(xì)化、構(gòu)造、移交四個(gè)階段每個(gè)階段有明確的目標(biāo)和里程碑。這三種方法論沒(méi)有絕對(duì)的優(yōu)劣之分關(guān)鍵看項(xiàng)目特征。項(xiàng)目需求比較明確且不常變、團(tuán)隊(duì)規(guī)模較大、對(duì)文檔要求高的瀑布模型未必不好需求不確定性強(qiáng)、需要快速驗(yàn)證的敏捷顯然更合適。從畢業(yè)設(shè)計(jì)角度來(lái)說(shuō)老老實(shí)實(shí)按瀑布模型來(lái)推進(jìn)通常是最穩(wěn)妥的因?yàn)槊總€(gè)階段都有明確的交付物可以給老師展示。6.2 項(xiàng)目排期與任務(wù)拆分的實(shí)操經(jīng)驗(yàn)不管用什么方法論項(xiàng)目排期和任務(wù)拆分都是躲不開(kāi)的管理工作。排期做得不好項(xiàng)目延期是必然的。任務(wù)拆分的核心單位是“用戶(hù)故事”也就是從一個(gè)用戶(hù)角度描述的一個(gè)功能點(diǎn)。一個(gè)良好的用戶(hù)故事要滿(mǎn)足INVEST標(biāo)準(zhǔn)獨(dú)立的、可協(xié)商的、有價(jià)值的、可估算的、小的、可測(cè)試的。我自己拆任務(wù)的經(jīng)驗(yàn)是一個(gè)開(kāi)發(fā)任務(wù)控制在三到五個(gè)工日之內(nèi)完成。一旦拆出來(lái)的任務(wù)估時(shí)要超過(guò)一周就要考慮繼續(xù)細(xì)分否則風(fēng)險(xiǎn)的顆粒度太粗了。排期的時(shí)候要給風(fēng)險(xiǎn)留緩沖。很多項(xiàng)目延期的原因只有一個(gè)——所有估算都按“理想情況”來(lái)排完全沒(méi)考慮聯(lián)調(diào)耗時(shí)、測(cè)試返工、需求變更這些必然發(fā)生的事。我通常會(huì)在整個(gè)項(xiàng)目工期后面額外加百分之二十的緩沖時(shí)間分散到各個(gè)階段里。6.3 團(tuán)隊(duì)協(xié)作效率與溝通機(jī)制開(kāi)發(fā)流程能不能順利推進(jìn)很大程度取決于團(tuán)隊(duì)的溝通協(xié)作效率。流程是骨架溝通才是血液。每日站會(huì)是最常見(jiàn)的敏捷實(shí)踐之一十五分鐘左右每個(gè)人都回答三個(gè)問(wèn)題昨天我做了什么今天我打算做什么我遇到了什么阻礙站會(huì)的價(jià)值不在于匯報(bào)而是讓問(wèn)題盡早暴露——誰(shuí)被卡住了、哪兩個(gè)模塊的接口對(duì)不齊、哪個(gè)環(huán)境壞了。這些都是日常開(kāi)發(fā)中真正阻礙進(jìn)度的事情。除了站會(huì)我這里強(qiáng)烈建議團(tuán)隊(duì)沉淀文檔。這里的文檔不是指巨大而全面、寫(xiě)完就沒(méi)人看的內(nèi)部知識(shí)庫(kù)而是圍繞當(dāng)前項(xiàng)目的輕量級(jí)協(xié)作記錄接口變更記錄、環(huán)境配置手冊(cè)、發(fā)布操作手冊(cè)、常見(jiàn)問(wèn)題清單。維護(hù)一份高可用的文檔比想象中要有價(jià)值得多。我自己在做開(kāi)源項(xiàng)目的時(shí)候也體驗(yàn)過(guò)流程的影響。一個(gè)開(kāi)源倉(cāng)庫(kù)能吸引外部貢獻(xiàn)者長(zhǎng)期參與靠的往往不是激情而是清晰好上手的貢獻(xiàn)指南、編碼規(guī)范、issue管理規(guī)范這些本質(zhì)上就是軟件工程流程的外化。6.4 面向?qū)W生的軟件工程課程與畢設(shè)生存指南這個(gè)內(nèi)容的熱門(mén)搜索詞里有不少關(guān)于軟件工程課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)、畢業(yè)設(shè)計(jì)選題的內(nèi)容說(shuō)明有大量學(xué)生朋友正在經(jīng)歷類(lèi)似的挑戰(zhàn)。我也帶過(guò)不少實(shí)習(xí)生看過(guò)很多學(xué)生的課程項(xiàng)目和畢設(shè)還是有一些經(jīng)驗(yàn)可以分享的。關(guān)于畢業(yè)設(shè)計(jì)選題核心原則有三條選熟悉的領(lǐng)域不選陌生的概念選技術(shù)有積累的方向不選完全陌生的技術(shù)棧選范圍可控的題目不選宏大空泛的題目。有些同學(xué)喜歡追求“高尖端”上來(lái)就要做區(qū)塊鏈、人工智能平臺(tái)。我的看法是本科畢設(shè)的核心價(jià)值是展現(xiàn)完整的軟件工程過(guò)程而不是展示某個(gè)高深的技術(shù)點(diǎn)。一個(gè)把需求分析、系統(tǒng)設(shè)計(jì)、編碼測(cè)試做得扎實(shí)的普通管理系統(tǒng)在答辯中的表現(xiàn)通常好過(guò)一個(gè)做完上線模塊都沒(méi)跑通的高大上系統(tǒng)。課程設(shè)計(jì)的時(shí)間管理也是一個(gè)重點(diǎn)。課程設(shè)計(jì)通常只有一個(gè)學(xué)期如果按部就班地走完整套流程是來(lái)得及的但前提是從一開(kāi)始就進(jìn)入狀態(tài)。我把一個(gè)典型的課程設(shè)計(jì)周期拆解如下供參考時(shí)間段階段關(guān)鍵任務(wù)第1周需求分析確定題目、做需求調(diào)研、完成需求文檔第2-3周系統(tǒng)設(shè)計(jì)完成總體架構(gòu)和數(shù)據(jù)庫(kù)設(shè)計(jì)第4-8周編碼實(shí)現(xiàn)前后端開(kāi)發(fā)、單元測(cè)試第9-10周測(cè)試完善集成測(cè)試、修復(fù)缺陷、完善界面第11-12周文檔與答辯撰寫(xiě)論文/報(bào)告準(zhǔn)備演示和答辯PPT我見(jiàn)過(guò)太多同學(xué)把前八周用來(lái)“思考”“準(zhǔn)備”最后四周瘋狂趕工結(jié)果就是代碼質(zhì)量差、文檔拼湊、答辯時(shí)漏洞百出。反過(guò)來(lái)按流程一步步來(lái)每個(gè)階段都有產(chǎn)出最后的總結(jié)和答辯反而是水到渠成的事情。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄軟件開(kāi)發(fā)流程不是一套死板的流程模板而是在反復(fù)實(shí)踐中打磨出來(lái)的一套解決問(wèn)題的方法論。這里我把實(shí)操中最常遇到的幾個(gè)問(wèn)題整理出來(lái)都是大家容易踩的坑希望能幫你少走些彎路。7.1 需求永遠(yuǎn)在變?cè)趺崔k問(wèn)題描述需求頻繁變更團(tuán)隊(duì)疲于奔命開(kāi)發(fā)進(jìn)度一拖再拖。排查思路先要分清需求變更的原因。是因?yàn)樾枨蟊旧聿磺逦捌跍贤ú怀浞诌€是因?yàn)闃I(yè)務(wù)環(huán)境確實(shí)在變或者是客戶(hù)“隨便想想”隨口提的需求不同原因?qū)?yīng)不同的解決策略。實(shí)操建議需求階段盡量把業(yè)務(wù)規(guī)則問(wèn)細(xì)、問(wèn)透用原型圖或者可交互Demo來(lái)確認(rèn)而不是只靠文字描述建立變更控制機(jī)制每輪變更加上評(píng)估環(huán)節(jié)量化變更帶來(lái)的工期影響并讓需求方為這個(gè)成本負(fù)責(zé)將需求按優(yōu)先級(jí)分層核心功能絕不調(diào)整非核心功能作為可選項(xiàng)變更時(shí)優(yōu)先砍掉低優(yōu)先級(jí)需求7.2 設(shè)計(jì)文檔寫(xiě)完了沒(méi)人看怎么辦問(wèn)題描述費(fèi)勁寫(xiě)了一大堆設(shè)計(jì)文檔開(kāi)發(fā)過(guò)程中根本沒(méi)人按照文檔執(zhí)行代碼和設(shè)計(jì)脫節(jié)。這個(gè)問(wèn)題在不少團(tuán)隊(duì)都存在。原因通常是設(shè)計(jì)文檔的“度”沒(méi)把握好寫(xiě)得太細(xì)開(kāi)發(fā)覺(jué)得被束縛、文檔更新也跟不上寫(xiě)得太粗開(kāi)發(fā)不知道如何落地看完等于沒(méi)看。實(shí)操建議設(shè)計(jì)文檔的細(xì)致程度要與項(xiàng)目規(guī)模匹配。五個(gè)人以下的小項(xiàng)目不需要兩百頁(yè)的重文檔模塊關(guān)系圖加關(guān)鍵接口定義就夠了文檔里的模棱兩可的表述一律改成明確的決策。比如不確定的地方畫(huà)個(gè)問(wèn)號(hào)文檔評(píng)審時(shí)集中討論解決不帶偷入開(kāi)發(fā)階段建立設(shè)計(jì)評(píng)審機(jī)制開(kāi)過(guò)會(huì)、改過(guò)版、會(huì)簽過(guò)的設(shè)計(jì)才算數(shù)。開(kāi)發(fā)過(guò)程中發(fā)現(xiàn)設(shè)計(jì)與實(shí)際沖突的要把差異反饋回設(shè)計(jì)文檔盡量保持文檔和代碼同步更新7.3 測(cè)試階段突然大量爆出問(wèn)題怎么辦問(wèn)題描述前期開(kāi)發(fā)感覺(jué)很順暢一到測(cè)試階段缺陷數(shù)量激增項(xiàng)目瀕臨失控。這個(gè)問(wèn)題背后的核心原因往往是前期自測(cè)不足或者測(cè)試用例覆蓋到了開(kāi)發(fā)人員沒(méi)有考慮到的場(chǎng)景又或者是集成環(huán)境引入了新的問(wèn)題。排查思路先對(duì)缺陷做分類(lèi)統(tǒng)計(jì)判斷缺陷主要集中在功能邏輯還是環(huán)境配置還是接口交互有的放矢緊急缺陷要求開(kāi)發(fā)優(yōu)先修復(fù)一般缺陷進(jìn)入缺陷池按優(yōu)先級(jí)處理缺陷處理完后要復(fù)盤(pán)根因是開(kāi)發(fā)自測(cè)不充分還是需求理解偏差還是流程環(huán)節(jié)缺失從根上解決問(wèn)題實(shí)操建議在編碼階段就推行“開(kāi)發(fā)自測(cè)清單”要求開(kāi)發(fā)在提交代碼前先在本地把主要的端到端流程跑一遍。這條看似普通的規(guī)則能擋住測(cè)試階段大量低級(jí)缺陷。7.4 小團(tuán)隊(duì)的輕量級(jí)流程落地姿勢(shì)問(wèn)題描述團(tuán)隊(duì)總共就三五個(gè)人做全套流程感覺(jué)官僚主義不做又總是出問(wèn)題怎么平衡這個(gè)問(wèn)題是很多小團(tuán)隊(duì)和初級(jí)項(xiàng)目管理者最糾結(jié)的。我的觀點(diǎn)很明確小團(tuán)隊(duì)不需要重型流程但必須有輕型流程。這里的重心要放在高價(jià)值的環(huán)節(jié)上——需求階段做一次完整的口頭澄清加一份一頁(yè)紙的需求摘要不做大而全的SRS文檔設(shè)計(jì)階段畫(huà)好關(guān)鍵的系統(tǒng)架構(gòu)圖和數(shù)據(jù)庫(kù)ER圖文字說(shuō)明精簡(jiǎn)干練編碼階段堅(jiān)持代碼規(guī)范工具化和Code Review測(cè)試階段保證核心功能有自動(dòng)化測(cè)試版本管理嚴(yán)格執(zhí)行Git Flow精簡(jiǎn)版這些是花時(shí)間少但回報(bào)率高的實(shí)踐本質(zhì)上是在控制風(fēng)險(xiǎn)和維護(hù)效率之間找一個(gè)最佳的平衡點(diǎn)。我自己帶小團(tuán)隊(duì)做項(xiàng)目時(shí)就踐行這套路徑效果穩(wěn)定團(tuán)隊(duì)的負(fù)擔(dān)也不算大。7.5 畢業(yè)設(shè)計(jì)與課程設(shè)計(jì)的常見(jiàn)通關(guān)技巧針對(duì)學(xué)生群體我再單獨(dú)整理幾條實(shí)操建議選題時(shí)避開(kāi)“大而全”的題目。“口紅機(jī)商城系統(tǒng)”“智慧校園綜合平臺(tái)”這類(lèi)題目聽(tīng)著高大上做完累死人答辯還有被圍攻的風(fēng)險(xiǎn)。選一個(gè)具體的小場(chǎng)景比如“基于Python的學(xué)生選課推薦系統(tǒng)”麻雀雖小但五臟俱全反而容易講得深入。論文和項(xiàng)目交付物的關(guān)聯(lián)性要強(qiáng)。很多同學(xué)的代碼是一套論文里寫(xiě)的又是另一套論文答辯時(shí)老師一提問(wèn)就露餡。正確的做法是先明確論文要講什么故事再按照故事的結(jié)構(gòu)去實(shí)現(xiàn)系統(tǒng)讓論文和代碼互相印證。演示環(huán)節(jié)提前演練至少三遍。尤其注意準(zhǔn)備備用數(shù)據(jù)、備用賬號(hào)、斷網(wǎng)應(yīng)急預(yù)案。我見(jiàn)過(guò)不止一個(gè)同學(xué)答辯現(xiàn)場(chǎng)因?yàn)閃i-Fi斷了、數(shù)據(jù)庫(kù)沒(méi)啟動(dòng)、接口超時(shí)把演示搞砸了。提前準(zhǔn)備好本地環(huán)境該錄屏的錄屏該截圖的截圖。8. 流程的裁剪與工程化思維的內(nèi)化說(shuō)完了具體流程和常見(jiàn)問(wèn)題最后再把視角抬高一點(diǎn)聊聊工程化思維這件事。我做軟件這十幾年來(lái)最大的體會(huì)是軟件開(kāi)發(fā)流程不是一堆死板的文檔和會(huì)議而是一種工程化思維的體現(xiàn)。這種思維的核心是把“憑感覺(jué)做事”變成“按章法做事”把“靠個(gè)人英雄主義推進(jìn)”變成“靠體系保障”。工程化思維體現(xiàn)在日復(fù)一日的小事里。寫(xiě)代碼之前先想清楚接口簽名是工程化提交代碼前先跑一遍自動(dòng)化測(cè)試是工程化上線前寫(xiě)好回滾方案是工程化。這些東西單個(gè)來(lái)看都不起眼但組合起來(lái)就是普通開(kāi)發(fā)者和優(yōu)秀工程師之間的差距所在。流程的裁剪能力也是工程化思維的重要部分。拿到一個(gè)項(xiàng)目要根據(jù)它的規(guī)模、特點(diǎn)、風(fēng)險(xiǎn)等級(jí)來(lái)調(diào)整流程的分量——大型項(xiàng)目需要完整流程和必要的評(píng)審關(guān)卡小型項(xiàng)目只要提煉出核心實(shí)踐就能高效運(yùn)轉(zhuǎn)。照搬模板是做不好軟件工程管理的理解流程背后的目的才能有針對(duì)性的取舍。以熱詞里的整車(chē)開(kāi)發(fā)流程來(lái)說(shuō)它比通用軟件流程多了很多物理驗(yàn)證環(huán)節(jié)概念設(shè)計(jì)、數(shù)字模型評(píng)審、油泥模型、樣車(chē)測(cè)試然后才量產(chǎn)。你當(dāng)然不能把汽車(chē)制造的全套流程套到一個(gè)小程序開(kāi)發(fā)上但其中“階段門(mén)”的思想——每一階段設(shè)一個(gè)質(zhì)量關(guān)卡不通過(guò)不進(jìn)入下一階段——對(duì)任何項(xiàng)目都是有效的。如果你現(xiàn)在正在學(xué)軟件工程導(dǎo)論相關(guān)的課程或者正在準(zhǔn)備課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)我建議你不只是把流程當(dāng)成知識(shí)去記憶而是把它當(dāng)成工具去使用。找一個(gè)哪怕很小的題目完整地把需求分析、設(shè)計(jì)、編碼、測(cè)試、部署這個(gè)閉環(huán)走一遍。有時(shí)候?qū)W生問(wèn)我做軟件項(xiàng)目最捷徑的方法是什么我永遠(yuǎn)只會(huì)回答一句話把一個(gè)項(xiàng)目完整地做完走完整個(gè)流程比什么都有用。最后分享一個(gè)我在實(shí)際項(xiàng)目里經(jīng)常用的小技巧每次項(xiàng)目迭代結(jié)束后團(tuán)隊(duì)花半小時(shí)做一次小型復(fù)盤(pán)每個(gè)人說(shuō)三件事——這次做得好的、這次做的不好的、下次要改進(jìn)的。不用寫(xiě)正式報(bào)告不用開(kāi)會(huì)正式匯報(bào)就是閑聊式的坦誠(chéng)交流。這個(gè)小習(xí)慣對(duì)團(tuán)隊(duì)和個(gè)人的成長(zhǎng)幫助遠(yuǎn)超一次完整的項(xiàng)目總結(jié)報(bào)告。這背后體現(xiàn)的其實(shí)也是軟件工程流程最有價(jià)值的那個(gè)部分它讓優(yōu)秀可以被復(fù)制讓失誤可以被避免。