研發效率破局之道閱讀總結(3)工程優化

Author: Once Day Date: 2025年4月22日

一位熱衷于Linux學習和開發的菜鳥，試圖譜寫一場冒險之旅，也許終點只是一場白日夢…

漫漫長路，有人對你微笑過嘛…

全系列文章可參考專欄: 程序的藝術_Once-Day的博客-CSDN博客


注: 本文內容摘抄于原文，文中"我"代表原作者【葛俊】大佬視角。


參考文章:

• 研發效率破局之道

---

1. 軟件研發環境

按照開發流程，軟件研發需要以下幾種環境：

• 開發機器；
• IDE；
• 開發過程中使用的各種工具、數據和配置；
• 本地環境、聯調環境；
• 測試環境、類生產環境

Facebook 從不吝嗇在開發機器上的投資。每個開發人員除了有一臺筆記本外，還在遠程數 據中心有一臺開發機器。數據中心的機器用于后端以及網站的開發，為方便描述，我稱之為 后端開發機。而筆記本有兩個用處：一是用來做移動端 App 的開發；二是作為終端，連接 到后端開發機做后端和網站開發。

兩臺機器的配置都非常強勁。后端開發機一開始是實體機器，后來為了便于管理和提高資源利用率，逐步轉為了虛擬機，但不變的是配置依然強大。在 2015 年的時候，絕大部分機器 配置都能達到 16 核 CPU 、144G 內存。筆記本有兩種選擇，一種是蘋果 MacBook Pro， 另一種是聯想 ThinkPad，都是當時市場上頂配或者頂配下一級的配置。

配置高效的研發環境主要包括以下幾條原則：

• 舍得投入資源，用資源換取開發人員時間。
• 對環境的獲取進行服務化、自助化。
• 注重環境的一體化、一致性，也就是要把團隊的最佳實踐固化下來。

2. 如何做好代碼審查

做好代碼審查的一個前提條件就是，要找到適合自己團隊的方法。

按照定義，人工檢查才是代碼審查。機器進行的檢查一般叫作代碼檢查或者代碼自動檢查。

代碼審查的作用很多，主要表現在 5 個方面。

• 盡早發現 Bug 和設計中存在的問題。我們都知道，問題發現得越晚，修復的代價越大。代碼審查把問題的發現盡量提前，自然會提高效能。
• 提高個人工程能力。不言而喻，別人對你的代碼提建議，自然能提高你的工程能力。事實上，僅僅因為知道自己的代碼會被同事審查，你就會注意提高代碼質量。
• 團隊知識共享。一段代碼入庫之后，就從個人的代碼變成了團隊的代碼。代碼審查可以幫助其他開發者了解這些代碼的設計思想、實現方式等。
• 針對某個特定方面提高質量。一些比較專業的領域，比如安全、性能、UI 等，可以邀請專家進行專項審查。另外，一些核心代碼或者高風險代碼，也可以通過團隊集體審查的方式來保證質量。
• 統一編碼風格。

按照審查方式，代碼審查可以分為工具輔助的線下異步審查和面對面審查兩類。

• 工具輔助的線下異步審查，就是代碼作者通過工具將代碼發送給審查者，審查者再通過工具把反饋傳遞給作者。可以控制審查時間，減少對自己工作的干擾，會留下文檔，方便以后參考。
• 面對面審查，就是審查者和代碼作者在一塊兒閱讀代碼，進行實時討論。這種方式的好處是快，可以高效地審查不方便用文字討論的代碼。比如，架構問題的討論就很適合用這種方式。

事實上，有調查顯示，代碼審查更容易發現架構問題而不是 Bug。所以我的建議是，盡量使用代碼設計時審查。具體的方法是，可以使用與門禁代碼檢查相同的工具，只不過這個時候發出去的 PR 目的是為了討論，而不是為了入庫。討論結束后刪除這個 PR 即可。

代碼審查需要時間，這聽起來好像是廢話，但很多團隊在引入代碼審查時，都沒有為它預留 時間。結果是大家沒有時間做審查，效果自然也就不好。而效果不好又導致代碼審查得不到 管理者重視，開發人員更不可能將代碼審查放到自己的工作計劃中。于是，形成惡性循環， 代碼審查要么被逐漸廢棄，要么流于形式。

管理者要明確代碼審查是開發工作的重要組成部分，并記入工作量和績效考評。這是成功引入代碼審查的前提，再怎么強調都不為過。

成功推進代碼審查的關鍵操作:

• 代碼提交的原子性，是指一個提交包含一個不可分割的特性、修復或者優化，同時這個提交要盡可能小。
• 提高提交說明的質量，，好的格式應該包含：標題，詳細描述，測試情況，與其他工具和系統相關的信息。

代碼審查是兩個開發者之間的技術交流，雙方都要謹記互相尊重的原則。

從審查者的角度來看，在提出建議的時候，一定要考慮代碼作者的感受。最重要的一點是， 不要用一些主觀標準來評判別人的代碼。

在打回提交的時候，一定要禮貌地描述原因。審查要盡量及時，如果不能及時審查要告知作者。

代碼審查常常出現問題的一個地方是，在審查過程中因為意見不同而產生爭執甚至爭吵，所以一定記住代碼審查的目的是討論，而不是評判。討論的心態，有助于放下不必要的自尊心，從而順利地進行技術交流，提高審查效率。另外，討論的心態也能促進大家提早發出審查，從而盡早發現結構設計方面的問題。

審查者切記不要說教，說教容易讓人反感，不是討論的好方法。審查者提意見即可，不一定要提供解決方法。我曾經見過一個團隊要求提出問題必須給出對應的答案，結果是大家都不愿提問題了。

想辦法增加討論的有趣性。

3. 如何處理技術債

第一方面，要利用技術債的好處，必要時要大膽“舉債前行”。也就是說，在機會出現時， 使用最快的方式完成業務服務用戶，搶占市場先機，“不要在意那些細節”。

第二個方面，要控制技術債，在適當的時候償還適當部分的技術債。

控制技術債主要有以下 4 步：

• 讓公司管理層意識到償還技術債的重要性，從而愿意投入資源；
• 采用低成本的方式去預防；
• 識別技術債并找到可能的解決方案；
• 持續重構，解決高優先級技術債。

4. 測試如何應對新的開發模式

測試可以保證產品質量，重要性不言而喻。但，要做好測試也比較困難，需要克服很多挑 戰。尤其是，持續交付、敏捷開發等開發模式為傳統軟件測試方式帶來了更大的時間壓力。

我們先來看看下面這種熟悉的測試方式都有什么問題：

測試人員接到項目后參與需求評審， 然后根據需求文檔寫用例、準備腳本，等開發提測之后正式開始測試、提 Bug、回歸，測 試通過后就結束了，項目交給運維上線，之后投入下一個項目繼續重復這樣的流程。

這樣的流程看似沒什么錯，但有兩大問題：

• 測試人員非常被動。當需求質量、開發質量較差的時候，測試人員只能被動接受。
• 但同時，測試又被認為是質量的責任人。如果因為需求質量、開發提測質量差而導致上線 延期，大家通常會首先怪罪測試團隊。

這些問題，在新的開發模式下愈發嚴重。因為這些新的開發模式有一個共同點，就是要縮短 產品的交付周期，對自動化的要求越來越高，能夠專門留給傳統豎井流程中測試環節的時間 越來越短，自然更難保證質量。

測試左移和右移，就是把測試的范圍從傳統測試的節點中釋放出來，向左和右擴展。

• 向左擴展，就是讓測試介入代碼提測之前的部分。比如，擴展到開發階段，在架構設計時就考慮產品的可測試性，并盡量進行開發自測等。另外，測試可以更進一步擴展到需求評審階段，讓測試人員不只是了解需求，更要評估需求的質量，比如分析需求的合理性以及完整性等。
• 測試右移，是讓測試介入代碼提測之后的部分。比如，測試人員在產品上線過程中，利用線上的真實環境測試。另外產品上線之后，測試人員仍然介入，通過線上監控和預警，及時發現問題并跟進解決，將影響范圍降到最低。這樣一來，測試人員不但有更多的時間進行測試，還能發現在非生產環境中難以發現的問題。

要做好測試左移，有 3 個基本原則：

• 調整團隊對測試的態度。一個有效的辦法是，按照功能的維度管理團隊，讓整個功能團隊對產品負責。也就是說，如果產品質量出現問題， 不只是測試團隊“背鍋”，而是會影響整個功能團隊的績效。
• 把測試添加到開發和產品需求步驟中。常用的辦法是，讓測試人員參與到開發階段的方案設計中，了解開發的實現方式。因為很多開發人員可能只熟悉他負責的那一部分，而測試人員往往對全局更加了解，所以測試人員要評估改動范圍以及是否有遺漏的模塊 和系統。
• 頻繁測試，快速測試。在測試左移之前，我們需要等待提測，比較被動，不能頻繁測試。但測試左移到開發階段之后，我們就有了很大的自由度去頻繁運行測試，從而更好地發揮測試的作用，盡早發現更多的問題。

測試左移，本質上是盡早發現問題、預防問題。基本原則包括：從人的角度出發，讓產 品、開發、運維人員統一認識，重視測試；從流程上，讓測試融入產品設計和開發步驟中； 快速測試、頻繁測試。

其實，軟件開發行業早就達成了共識，問題發現得越晚，修復代價越大。

5. 各種部署的定義

藍綠部署（Blue-green Deployment）、紅黑部署（Red-black Deployment）和灰度發布（Gray Release ，或 Dark Launch）的定義和流程：

（1）藍綠部署，是采用兩個分開的集群對軟件版本進行升級的一種方式。它的部署模型中包括一 個藍色集群 A 和一個綠色集群 B，在沒有新版本上線的情況下，兩個集群上運行的版本是 一致的，同時對外提供服務。

• 首先，從負載均衡器列表中刪除集群 A，讓集群 B 單獨提供服務。
• 然后，在集群 A 上部署新版本。
• 接下來，集群 A 升級完畢后，把負載均衡列表全部指向 A，并刪除集群 B，由 A 單獨提供服務。
• 在集群 B 上部署完新版本后，再把它添加回負載均衡列表中。

（2）紅黑部署，與藍綠部署類似，紅黑部署也是通過兩個集群完成軟件版本的升級。當前提供服務的所有機器都運行在紅色集群 A 中，當需要發布新版本的時候：

• 先在云上申請一個黑色集群 B，在 B 上部署新版本的服務；
• 等到 B 升級完成后，我們一次性地把負載均衡全部指向 B；
• 把 A 集群從負載均衡列表中刪除，并釋放集群 A 中所有機器。

（3）灰度發布，也被叫作金絲雀發布。與藍綠部署、紅黑部署不同的是，灰度發布屬于增量發布方法。也就是說，服務升級的過程中，新舊版本會同時為用戶提供服務。

灰度發布的具體流程是這樣的：在集群的一小部分機器上部署新版本，給一部分用戶使用， 以測試新版本的功能和性能；確認沒有問題之后，再對整個集群進行升級。簡單地說，灰度 發布就是把部署好的服務分批次、逐步暴露給越來越多的用戶，直到最終完全上線。