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

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

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

編程與軟件工程

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

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

軟件工程發(fā)展史

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

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

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

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

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

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

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

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

Google軟件工程文化

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

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

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

團(tuán)隊(duì)協(xié)作的基石

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

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

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

打造知識(shí)共享文化

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

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

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

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

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

領(lǐng)導(dǎo)團(tuán)隊(duì)（Tech Lead）

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

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

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

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

工程效率測(cè)量

沒(méi)有測(cè)量就沒(méi)有優(yōu)化。只有測(cè)量到團(tuán)隊(duì)的工程效率后，我們才有可能制定提升效率的行動(dòng)。Google設(shè)計(jì)出了GSM框架來(lái)測(cè)量工程效率。

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

總結(jié)

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

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

審核編輯 ：李倩