在軟件工程的概念被提出之前，IT行業經歷了軟件危機[1]。當時IT行業開發的軟件正在經歷從小規模到大規模的過程，而沒有系統化的方法論指導大規模軟件的開發過程，導致軟件工程師之間的協作非常的低效且質量難以得到保證。

直到IT行業意識到軟件需要一種工程化的方法論來指導開發過程。

軟件工程是將系統化的、規范的、可度量的方法用于軟件的開發、運行和維護的過程，即將工程化應用于軟件開發中（IEEE，1993）。

編程與軟件工程

編程是利用某個編程語言實現某個算法或技術方案從而來解決某類問題，但這類問題規模一般很小，也不太會隨著時間產生變化，或者其生命周期也很短，不需要考慮長期維護的問題。但軟件工程與編程的區別在于前者需考慮時間與規模帶來變化的影響。

時間的因素使軟件工程需要考慮質量的問題，糟糕的質量會產生很多認知負荷，最終難以長期維護。規模的因素使軟件工程需要考慮協作的問題，低效的協作可能與溝通方式有關，最終拖垮交付進度。

軟件工程發展史

早期的軟件工程借鑒了項目管理的流程，而傳統的項目管理關注生產過程大過于人。

以過程為中心的軟件工程過程方法論主要有瀑布式與統一軟件開發過程。這種軟件開發過程需要產生大量的正式文檔，通過嚴格的流程管理控制軟件的開發過程。但軟件開發過程卻是一個知識密集型的生產過程，過于關注流程而忽略人的因素導致這類方法論很難適應需求變化，花費很多時間開發出的產品很難滿足變化迅速的市場，最終逐漸被淘汰。

以人為中心的軟件開發過程是為適應需求變化的代碼編寫和團隊組織方法論。這類逐漸產生以極限編程與敏捷過程兩種方法論。

這里以敏捷過程為例，敏捷開發至今已經成為很主流的軟件開發過程。

敏捷開發倡導信任人而非死板的流程與計劃管理，通過一系列如上所示的實踐來營造一個信任為主的文化土壤，從而打造一個高效的研發團隊，最終開發出高質量的軟件成品。

當然本文不是介紹敏捷開發過程的，而是介紹Google公司的軟件工程實踐。

Google是一家偉大的互聯網公司，同時研發出來了大量知名的軟件產品。Google是怎么做到的？在2020年Google的三位工程師@TitusWinters[2]@manshreck[3]@hyrumwright[4]出版了《Software Engineering at Google[5]》這本書來介紹Google的軟件工程實踐，這給了我們一個機會一窺究竟。

本文是Google軟件工程系列的上篇之文化篇，來介紹軟件工程最重要的一個基石：文化要素。

Google軟件工程文化

以下是《Software Engineering at Google》一書第二部分文化篇的思維導圖，由于此部分占全書近20%，所以本文不會詳細的介紹其中的概念，想詳細了解的讀者建議閱讀原書。本文會結合此書這部分內容分享作者的個人理解及相關經驗。

文化為何是軟件工程很重要的一個要素？我在剛入IT行業時對軟件開發的理解只是學習某個編程語言來寫代碼。之后經過多年多個項目的歷練，我逐漸對整個軟件開發的全貌有了一定的理解。但還是停留在對軟件開發過程的了解及相關工具的使用，直到讀完這本書的文化篇后才意識到了文化的重要性。

文化雖然是和技術沒有直接關系的一些軟性的東西，但文化就像水一樣，利用好它的力量，可以讓軟件開發變得更高效、高質。

團隊協作的基石

軟件開發早已不是單兵作戰的時代了，雖然人們喜歡聽黑客奇跡般的故事，但現在的中大型軟件都是團隊的集體智慧產出。

如上是兩大頂級開源基金會@TheASF[6]與@linuxfoundation[7]的知名項目，成千上萬的軟件工程師的集體協作開發了達上億的代碼行數最終才誕生了這些偉大的項目。

而團隊協作最重要的是成員間的謙虛、尊重與信任。如果沒有這些最基本的條件，集體協作將會困難重重，團隊成員無法形成穩固的合作關系，時間和精力很容易被內耗完。

打造知識共享文化

軟件工程與傳統工程的區別在于其是一項知識密集型的活動，其中涉及到了大量的知識管理工作。知識管理[8]很容易做差，最終產生了以下的一些問題：

?缺乏心理安全：當一個新成員進入組織的時候，會因為缺乏心理安全感而不敢暴露自己不懂的知識，這會阻礙該成員的個人成長，最終也會傳導到團隊的開發效率上來。?知識孤島：知識沒有分享的文化土壤，每個團隊都悶頭搞自己的項目，會逐漸產生很多重復造輪子的現象。?知識單點故障：團隊內的重要信息只有一個人知道，而這個人又沒有分享給其他人，一旦這個人不在場，團隊將無法正常運轉。?團隊知識斷層：團隊內的技術專家并沒有意愿將個人的經驗傳授給團隊其它成員，導致團隊的運轉離不開一小部分技術專家，一旦這些人離開，整個團隊將無法正常運轉。?鸚鵡行為：這種很容易出現在團隊新成員，由于經驗限制或背景上下文了解有限，而在不了解其原理的情況下復制一些代碼。雖然系統可以運行，但潛在的埋下了一些問題。?知識禁區：團隊成員由于經驗限制或不了解背景上下文，而不敢修改代碼庫的某些遺留代碼。

這些都是組織學習文化中會遇到的一些挑戰。Google在打造知識共享文化上做了很多嘗試，比如營造安全的學習環境，鼓勵新人通過提問與分享來提高個人的技術。這些實踐在敏捷過程中也可以看到，比如：

?鼓勵個人反饋的文化（Feedback）。對事不對人，根據事實對成員提供建設性的反饋，幫助成員變的更好。?鼓勵團隊成員定期做分享（Session）。比如每周某個成員可以做某個主題的Session，這種實踐能讓分享者對分享的主題有更深的了解。?每日站會同步工作進度。不僅可以讓其它成員了解你所工作的范圍，還能告知其它成員潛在的交付風險。?定期回顧（Retro）。團隊定期舉行迭代回顧的會議，回顧最近工作中好的、不好的的方面及相關建議，最終制定出一些行動來提升團隊的工作效率、質量與幸福感。?團隊Wiki工作區。團隊知識沉淀的體現，新人可以通過查閱這些資料迅速了解項目背景上下文。?代碼評審（Code Diff）。代碼評審在Google的軟件工程中是一項全員必須執行的實踐。代碼評審可以提高團隊成員的編碼水平，發掘代碼潛在Bug，識別代碼壞味道，形成統一的編碼風格，共享業務與技術知識，消減團隊知識斷層的影響，甚至可以解決鸚鵡行為與知識禁區的問題。比如我所在的項目上團隊所有開發成員每天會拿出一小時做集體的Code Diff，雖然成本不低，但其收益也很高。?結對編程（Pair Programming）。結對編程看起來是兩個人在做一個人的活，但一般也有兩種模式：乒乓模式（Ping-Pong）與領航員觀察者模式（Navigator-Observer），前者適合以TDD的方式開發，后者適合老帶新。結對編程是成本高但非常高效的知識共享的實踐，需結合項目實際的帶寬決定當前是否采用此模式開發。比如我們項目會在交付時間不緊張時采用此開發模式。

以上的一些實踐需結合組織或項目的實際帶寬來決定是否使用，比如Code Diff一般是建議或者強制的，而結對編程是可選的，分享（Session）和回顧可能是定期或不定期的。

領導團隊（Tech Lead）

當做了一段時間獨立貢獻者（Individual Contributor）后，可能有機會做Tech Lead了。Tech Lead是一個團隊必備的角色，具有一定的職權影響力，當然更多的是采用非職權影響力去帶領團隊。

如何領導團隊是個復雜的工作，對技術人員來說，從技術到管理是很難的事情。

對于此我的個人經驗也不是很豐富，所以想了解此部分的推薦閱讀此書原文。當然下面這些文章也不錯：

?The Definition of a Tech Lead[9]?What Does a Software Tech Lead Do?[10]?Tech Lead[11]

工程效率測量

沒有測量就沒有優化。只有測量到團隊的工程效率后，我們才有可能制定提升效率的行動。Google設計出了GSM框架來測量工程效率。

工程效率的測量一般發生在大規模團隊或組織級別，我所經歷的項目上并沒有此實踐。對小型團隊來說，可以通過簡單的一些問卷調查這類定性的方式來收集團隊成員的反饋，當然也可以通過一些量化的指標如流水線構建速度、迭代開發速率、代碼靜態分析結果、測試覆蓋率等指標測量團隊的工程效率。

總結

軟件工程是一項復雜的知識工程，這讓其區別于傳統的項目管理。Google的軟件工程文化與以人為中心的敏捷過程所倡導的理念有很多相似之處。

但反觀國內很多軟件公司雖然也用上了敏捷過程的方法論，但底層的文化土壤還是以過程為中心的方法論，對團隊成員的不信任，沒有分享文化，團隊領導一言堂還是存在的。希望這種現象能隨著國內IT行業的逐漸成熟越來越少吧。

審核編輯 ：李倩