這是心態(tài)的差別，或者說(shuō)，是技術(shù)境界的差別，烙在 Google 工程師的基因里，旁人想學(xué)也未必學(xué)得到。
3. “管理”二字的意義完全不同了
在 Google，有時(shí)候工程師很難管理，因?yàn)榇蠖鄶?shù)人都想法新、主意多、眼光高、個(gè)性強(qiáng)。在 Google，有時(shí)候工程師也很容易管理，只要鼓勵(lì)他們把一件看似普通的事兒做出世界級(jí)的水準(zhǔn)，他們自己就有足夠優(yōu)秀的執(zhí)行力，用不著督促。
在 Google 做技術(shù)經(jīng)理帶團(tuán)隊(duì)，和我以前在其他公司帶團(tuán)隊(duì)，完全是兩碼事。這也許和技術(shù)團(tuán)隊(duì)的平均水平有關(guān)，但 根本還是管理境界的問(wèn)題。
記得以前在別的公司，花大力氣搞開(kāi)發(fā)流程管理，現(xiàn)在想想，大多是繁文縟節(jié)，程式化，教條化，最極端的像 ISO9000 之類的流程認(rèn)證，弄得所有人筋疲力盡，效果未必有多好。
到了 Google，發(fā)現(xiàn)一個(gè)秘訣， 再多的規(guī)章制度，再多的流程，不如一套好用的工具來(lái)得有效。比如 Code Style 和 Code Review，以前能把技術(shù)經(jīng)理煩死，三令五申也執(zhí)行不下去，頂多三天熱度之后，大家就陽(yáng)奉陰違了。在 Google，這件事不完全是個(gè)制度的問(wèn)題。
剛進(jìn)來(lái)的工程師沒(méi)有過(guò) Readability Review，他就沒(méi)法方便地自主提交代碼，這是代碼管理工具設(shè)置的硬性限制。這直接把工程師們送到評(píng)審委員會(huì)那里接受“再教育”，沒(méi)錯(cuò)，真的是“再教 育”，連 Python 之父 Guido van Rossum 也花了挺大力氣才通過(guò)了 Python 語(yǔ)言代碼的 Readability Review。
接下來(lái)，提交新代碼前，各種靜態(tài)、動(dòng)態(tài)檢查工具自動(dòng)運(yùn)行，幫你報(bào)出一系列風(fēng)格錯(cuò)誤、編譯錯(cuò)誤、單元測(cè)試錯(cuò)誤和簡(jiǎn)單的邏輯錯(cuò)誤，你得先依著工具的提 示，把這些低級(jí)別錯(cuò)誤改一遍，然后才進(jìn)入 Peer Review 的環(huán)節(jié)。整個(gè) Code Review 都在非常方便的網(wǎng)頁(yè)工具里完成，寫(xiě)代碼的和審閱代碼的人可以方便地交互、討論，甚至在線修改代碼。
工具的“強(qiáng)制性”保證了制度的執(zhí)行，工具的“便捷性”最大程度減輕了工程師執(zhí)行制度的負(fù)擔(dān)，二者相輔相成。當(dāng)然，Google 內(nèi)部也不乏對(duì)制度敷衍了事的，但相對(duì)其他公司，Google 的確做得更好些。