在軟件工程的概念被提出之前，IT行業(yè)經(jīng)歷了軟件危機[1]。當(dāng)時IT行業(yè)開發(fā)的軟件正在經(jīng)歷從小規(guī)模到大規(guī)模的過程，而沒有系統(tǒng)化的方法論指導(dǎo)大規(guī)模軟件的開發(fā)過程，導(dǎo)致軟件工程師之間的協(xié)作非常的低效且質(zhì)量難以得到保證。

直到IT行業(yè)意識到軟件需要一種工程化的方法論來指導(dǎo)開發(fā)過程。

軟件工程是將系統(tǒng)化的、規(guī)范的、可度量的方法用于軟件的開發(fā)、運行和維護的過程，即將工程化應(yīng)用于軟件開發(fā)中（IEEE，1993）。

編程與軟件工程

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

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

軟件工程發(fā)展史

早期的軟件工程借鑒了項目管理的流程，而傳統(tǒng)的項目管理關(guān)注生產(chǎn)過程大過于人。

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

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

這里以敏捷過程為例，敏捷開發(fā)至今已經(jīng)成為很主流的軟件開發(fā)過程。

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

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

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

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

Google軟件工程文化

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

文化為何是軟件工程很重要的一個要素？我在剛?cè)隝T行業(yè)時對軟件開發(fā)的理解只是學(xué)習(xí)某個編程語言來寫代碼。之后經(jīng)過多年多個項目的歷練，我逐漸對整個軟件開發(fā)的全貌有了一定的理解。但還是停留在對軟件開發(fā)過程的了解及相關(guān)工具的使用，直到讀完這本書的文化篇后才意識到了文化的重要性。

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

團隊協(xié)作的基石

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

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

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

打造知識共享文化

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

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

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

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

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

領(lǐng)導(dǎo)團隊（Tech Lead）

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

如何領(lǐng)導(dǎo)團隊是個復(fù)雜的工作，對技術(shù)人員來說，從技術(shù)到管理是很難的事情。

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

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

工程效率測量

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

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

總結(jié)

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

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

審核編輯 ：李倩