1.6 怎么運轉項目

無論團隊管理還是項目管理都需要一個運轉機制。就像內燃機一樣，通過內能和機械能的相互轉化，驅動車輪向前、向后開動。我們常見的汽油機是活塞式內燃機，它將燃料和空氣混合，在汽缸內燃燒，釋放出的熱能使汽缸內產生高溫高壓的燃氣，推動活塞做功，再通過曲柄連桿將機械功輸出，驅動從動機械工作。

目前，我們已經具備了氣缸（平臺）、活塞（度量指標）、燃料（從上到下的支持）和空氣（分支策略）這些必備條件，只欠“外力點火”和“周期性柄桿驅動”這股東風。

所謂“外力點火”，就是我們主動去激發一線研發人員去發現問題，尋找問題的解決方案，聯動各技術負責人尋找最優解。所以，我們啟動了頻繁構建實踐，幫助研發人員找到解決方法。

所謂“周期性柄桿驅動”，就是我們聯動技術團隊從上到下，按照一定的規范和頻率將內部齒輪轉動起來。所以，我們通過分層會議落實技術團隊代碼質量保障工作。

當技術團隊不再認為代碼質量提升是額外任務（工作量）的時候，這些規范就可促使工程師們形成研發習慣。當這些規范經過沉淀后，研發習慣則逐步演變為工程師文化的一部分。

下面通過項目場景分析法逐步剖析，如圖1-15所示。其中，業務流程和用戶行為已經在上文分析完畢。接下來，我們將重點講解實施原則和改進方法，為讀者展示一幅完整的代碼質量提升解決方案畫卷。

1.6.1 頻繁構建，持續發現

項目啟動一個月后發現，雖然我們已經將指標和代碼分支策略與研發團隊達成一致意見，但從每周的數據趨勢圖可看出，代碼質量問題總數量還在呈小幅上升趨勢。前兩周大家還抱著一腔熱血去解決問題，但隨著增量代碼一直新增問題，導致問題總量看起來整體變化并不大。一個月過后，大家的激情也快退卻了。

于是，我們想起上文提到的研發輔助性指標，立即改變了策略，將之前的輔助性指標作為核心指標，讓研發人員先解決增量問題，先把流程走起來，流程走順了之后，再去解決存量問題。

當時，我們以為找到了“良藥”，但項目運轉兩周后發現另外一個現象：研發人員每次提交的增量代碼中問題也很多。他們遇到緊急上線情況時，不管那些壞味道問題，只要不影響業務核心邏輯，那就按時上線。這件事情也很好理解，研發人員與其延期交付，不如先將代碼質量問題放一放，下次迭代再解決。

幸運的是，我們很快發現了這個問題，并深入經常出現這類問題的團隊進行調研，發現一個致命問題——研發人員集中提交代碼，即代碼在本地積累一段時間后批量提交，并在同一時間進行合并。

這個問題為什么嚴重，我給大家舉一個例子。假如我想減肥，于是定了一個小目標：一個月減10kg。設想一下，我能否在每天不鍛煉的情況下，到月底最后一天通過一天一夜的跑步減掉10kg？答案是肯定的：不能。假如我堅持每天跑步鍛煉，每天只需要減重0.33kg即可達成目標。從可實現性上看，顯然第二種方式比較容易達成目標。

雖然以上案例非常不健康，但它說明一個淺顯易懂的道理：做事情要天天堅持。代碼質量問題的發現和解決也是，需要分配到每天去做。

這也是持續交付的一種思想：通過頻繁構建，持續發現問題，每天小步解決，持續試錯。有了方法論做支撐，下面我們看看如何實施吧！

1.6.2 找方法，定原則

基于當前的嚴峻形勢，我們緊急召開了代碼質量委員會，組織各部門技術負責人一起討論了問題的嚴重性，達成如下兩個一致性原則。

1.堅持每天構建一次流水線原則

會議達成一致意見，要求所有研發人員必須每天將在本地驗證通過的代碼，在下班前提交到遠程分支并觸發流水線構建，直至構建流水線的代碼質量門禁強制校驗通過，方可認為當日代碼質量通過。

下面將為研發人員提供本地代碼驗證方法以及質量門禁檢測方法。

1）每天每個開發人員對新增代碼在本地進行檢查并確保通過。

若你的IDE是IntelliJ IDEA，可執行如下操作。

① 一線研發人員將本地代碼提交到遠程Sonar服務器，并通過Sonar平臺獲取本地代碼質量指標。我們會將詳細配置步驟以及獲取指標方法給到研發人員。之后，研發人員可到Sonar平臺根據對應項目和分支名找到靜態代碼質量分析結果。

②在IDEA中安裝SonarLint插件，配置并獲取遠程Sonar服務器中各語言的代碼檢查規則，手動操作獲取或者通過配置實時獲取當前文件和當前項目的代碼質量報告。其運行效果如圖1-16所示。

2）將本地代碼提交到遠程分支，并通過質量門禁強制檢查。

起初，我們通過Sonar平臺統一配置各項目的質量門禁，并將代碼檢查接入GitLab流水線。如圖1-17所示，當研發人員將本地代碼提交后，流水線構建會自動觸發；構建結束后，GitLab會發送一封郵件給到觸發者。

幾個月之后，我們將實現頻繁構建的這些功能落實到自運維管理平臺，并基于GitLab平臺的底層邏輯擴展了其他功能。之后，我們便可以進行質量門禁設置和校驗檢查。運行效果如圖1-18所示（和圖1-17是同一個執行流程）。

當團隊養成每天至少構建一次流水線的習慣時，你還會擔心他們不會每天頻繁構建流水線嗎？他們會慢慢發現頻繁做這件事的“紅利”。

2.堅持今日事今日畢原則

會議達成一致意見，要求所有研發人員必須解決當日流水線構建時出現的所有問題，方可認為當日工作完成。而效能團隊作為提供解決方案的友好“供應商”，必須做好實時響應的準備，具體做法如下。

1）通過匯總的消息驅動各研發團隊負責人跟進團隊當日工作完成度。

各研發團隊（小組）負責人在下班前，將收到平臺發送的一個匯總報告消息。同時，平臺將各部門的指標發送到部門負責人；而一線研發人員在下班前將被告知：當天流水線被構建了多少次，還有哪些流水線未通過。

匯報信息包含部門（團隊）當天“流水線通過率”和成員的“平均構建次數”，并可超鏈接到平臺，以便負責人進一步下鉆分析哪個團隊（小組）、哪個服務、哪個負責人、哪條流水線未通過（點擊流水線可查看未通過的原因）。

圖1-19展示了質量門禁校驗未通過，導致流水線構建失敗。

2）通過大屏播報，推進研發團隊及時發現和解決當天積累的問題。

大家在學習精益管理時，想必都聽過豐田公司的“安燈系統”。公司每個設備或工作站都裝配有安燈系統，如果生產過程中發現問題，操作員（或設備）會將燈打開引起注意，使得問題得到及時處理，避免生產中斷或減少問題重復發生。

這里有一個非常重要的概念是：安燈系統并不是我們理解中的叫停產線，而是在出現問題的地方“亮燈”，呼叫支持團隊及時來解決問題。

我們吸收了這個理念后，對平臺設計進行了思考。

我們在每個集中辦公地點設置了一個大屏顯示器，這個顯示器一定要擺放在最顯眼的地方。該顯示器可顯示我們的平臺頁面，目前功能比較簡單，只能輪播各團隊的流水線和代碼質量情況。當團隊負責的流水線執行失敗且未解決的流水線總數超過5時，系統會發送一個信息給相應團隊負責人，同時播報，如××團隊××個流水線執行失敗，請團隊負責人××及時協助解決。

團隊負責人或指定的小組負責人聽到播報后，必須及時過來關閉播報窗口，并立刻協助團隊成員解決積累的問題。

這個舉措效果非常好，我們看到線下溝通現象增多，一線研發人員遇到的問題也能在團隊負責人的幫助下及時得到解決。大屏顯示促使各團隊成員產生“比賽”心理：你們做得好，我們要做得更好。這也能夠讓我們始終保持活力，并保持對數據的敬畏。

不過，前期也有人反對此事，他們覺得播報會打斷開發人員的工作。所以，前期需要多調節觸發播報的閾值，找到一個合適的冒紅燈頻次，目的是想讓一線研發人員遇到的問題能夠及時得到解決，并不斷加強此氛圍。不過，對于頻繁被播報的團隊，我們會私下約負責人和CTO溝通。

代碼質量問題如何解決、單測覆蓋率如何提升等，我們將在第2章詳細講解。

若質量門禁設置合理，所有代碼質量通過檢查，就能夠直接部署到對應環境。運維豈不是可以節省時間做更有價值的事。運維是這么想的，我們也是這么想的，這些功能的實現將在第3章詳細講解。

倘若當前研發人員能夠堅持做到頻繁構建，并可駕馭自運維管理平臺，也知道如何解決這些問題，如何讓這個流程持續運轉起來？如果研發人員只能堅持一段時間或者技術負責人帶著小組成員去做其他事情，代碼質量提升是不是要擱置了？我們會定期組織分層會議，讓這件事情持續下去。

1.6.3 分層會議，周期性運轉

我們舉行會議的目的是讓技術團隊從上到下都能夠參與到代碼質量治理過程中，通過3個不同層次的會議持續運營，以分層指標和解決方法分享推動CTO、部門負責人、團隊負責人、一線研發人員持續關注代碼生命周期中不同階段的問題，進而落實項目（本書“參考資源”的第1章“場景案例”中提供了樣例）。

1.代碼質量委員會

會議的目的是讓部門負責人持續關注代碼架構設計、代碼模式設計、代碼質量問題，代碼的可擴展性、可讀性和規范性，并將其作為部門核心OKR，推進技術重構和代碼架構評審等實踐的落實，解決存量代碼問題。

該會議在每周五早上10點開始，持續時間約1h，由CTO主持，我們做記錄。

會議大致流程如下。

? 我們整理CTO和各部門負責人關注的核心指標，初步做出分析，時間約5min。

? 各部門負責人依次說明部門產生問題的原因、后續解決方案、何時能達標、誰牽頭負責，時間約15min。

? 每周輪流派一位負責人針對存量代碼中某一核心業務邏輯模塊，進行代碼設計等方面的問題總結和改進反思，時間約30min。

? 我們隨機抽查一個項目的一個模塊，針對代碼設計原則和代碼質量等方面的問題進行總結，時間約10min。

該會議前期由CTO主持，當部門間主要矛盾解決后便退出，交由我們主持和協調。該會議后來合并到每周的代碼質量保障協調會，每次持續20min左右，可見技術團隊對代碼質量的重視程度。

2.代碼質量治理會

會議的目的是讓團隊負責人重視代碼質量和代碼設計，交流解決方案，相互賦能，從而做到知識共享，共同提升，推進代碼評審和質量門禁實踐的落實。

參會對象是每周問題較多的項目所屬的團隊負責人，以及想了解其他組解決方法的團隊負責人。

該會議每兩周舉行一次，一般在周五下午2點（早上部門負責人剛開完會，明確了問題，此時他們急需解決方法），持續時間約1h，由我們組織并做記錄。后續各部門每隔一個季度輪流主持并做會議紀要。

會議大致流程如下。

? 我們整理項目問題，按照部門、團隊進行問題分析。構建數據分析平臺后，主持人只需打開平臺頁面即可直接分析，時間約10min。

? 各小組負責人輪流說明各團隊（項目）出現問題的原因、后續解決方法、何時達標、誰牽頭解決，時間約20min。

? 上周遇到問題比較多的小組進行解決方案分享，保證每次會議都有輸出，時間約20min。

? 我們整理近一周各團隊遇到的共性問題并分享解決思路，時間約10min。

以上流程會隨著當周問題的多少、嚴重程度等適當調整。

3.代碼質量分享會

會議目的是讓一線研發人員解決各種場景下的代碼質量問題，學會如何結合平臺與工程實踐方法提升個人的技術水平和解決問題的能力，推進研發人員落實單測等實踐。

會議形式是“在線會議+飛書直播”，還可錄屏后分享。

該會議不定期舉行，一般在周三下午，項目前期比較頻繁，后續慢慢減少，每次持續時間約40min，由我們組織。目前，我們已經積累非常多的解決方案并放到知識庫中，供所有研發人員參考。持續兩個OKR周期后，該會議合并到技術培訓組組織的技術分享會中，不再單獨召開。

會議大致流程如下。

? 我們整理各場景下代碼質量問題的解決方法并進行分享，持續時間約20min。

? 各研發人員提問，我們進行答疑和討論，持續時間約20min。

這些原則、流程和實踐方法達成一致時，就形成了默認的規范，進而構成研發生態鏈。

1.6.4 構成生態，養成習慣

對代碼生命周期中每個關鍵活動（見圖1-20）的質量檢查，相當于為進入下一個活動設置了門檻（質量關卡）。當代碼通過層層篩選和把關后，我們認為這些代碼是可靠的，是具有魯棒性的。這些檢查活動按照順序依次執行下去時，便形成了技術團隊研發流程；這些原則和方法整理成文時，便形成了技術團隊研發規范。

下面介紹代碼生命周期中不同的關鍵活動階段的代碼質量檢查。

（1）代碼編寫階段

該階段的代碼質量檢查可自動化執行。研發人員可在IDEA上通過SonarLint實時查看代碼質量問題，及時發現，及時解決。

（2）代碼提交階段

該階段的代碼質量檢查可自動化執行。效能團隊在GitLab上配置阿里代碼檢查工具P3C。代碼未通過檢查，將無法提交，進而無法觸發流水線的構建。同時，GitLab會向代碼提交者發送消息和郵件，詳細描述代碼哪里不符合規范，修正后可再次提交。

（3）代碼評審階段

該階段的代碼質量檢查需人工執行。效能團隊在GitLab上配置合并請求（Merge Request）。團隊負責人必須對研發人員提交的代碼進行評審，評審通過后方可合并并觸發流水線的構建。

該階段的目的是讓各團隊負責人關注代碼設計模式、代碼業務邏輯等方面的問題。

在評審之前，首先需要建立團隊的技術規范和標準，讓每個決策都有依據；其次需要加強流程上的管理，建立周期性的技術架構評審機制，對架構的修改進行評審，一方面規避問題，另一方面根據問題完善規范和標準。

（4）代碼構建階段

該階段的代碼質量檢查可自動化執行。研發人員通過自運維管理平臺頻繁構建流水線，持續發現并解決代碼質量、性能和規范方面的問題，將技術債解決行為日常化；明確技術規范，加強管理，通過技術債務的可視化驅動一線研發人員分布式解決問題。

同時，設置質量門禁。研發人員必須解決掉所有增量代碼問題，這樣構建的流水線才能被執行，進而觸發不同環境的代碼部署。該過程由各團隊負責人指導實踐和落地。

（5）代碼回顧階段

每周組織一個部門進行代碼通曬，主要針對代碼塊問題的解決方案進行分享與分析。同時，效能團隊每周隨機抽查一個業務代碼模塊，主要從技術架構、技術框架、代碼設計等方面進行分析，驅動各部門主動進行代碼重構。

技術負責人在部門內部持續驅動存量代碼重構時，主要考慮以下幾點問題。

? 因認知不足或成本高而產生架構設計或代碼設計差的問題。

? 因能力或認知不足而選擇非最優技術框架的問題。

? 因成本高或進度慢而沒有完成代碼測試的問題。

隨著分層會議周期性運轉，以及各層級負責人把控代碼質量檢查成為每個研發人員的工作習慣。從此，代碼質量也成為研發團隊周會、站會以及日常溝通交流的話題。