[[234511]]

前言

人人都在說工程師文化，90%的同學(xué)們向往工程師文化，然而95%的同學(xué)們覺得自己的部門沒有工程師文化。但關(guān)于工程師文化，事實(shí)告訴我們兩件事：

• 事實(shí)1是：我們定義工程師文化的標(biāo)準(zhǔn)不一樣。這就跟美女一樣，每個(gè)人心中的美女都不一樣, 但我們都愛美女。
• 事實(shí)2是：工程師文化還是可以客觀感覺出來的。如果你真是個(gè)美女，大家還是都會(huì)認(rèn)為你漂亮的。標(biāo)準(zhǔn)再不一樣，敢說奧黛麗赫本丑的人還是需要莫大并且不要臉的勇氣。

基于這個(gè)不恰當(dāng)?shù)谋扔饕约笆聦?shí)1得出：90%同學(xué)們都愛美女；基于這個(gè)不恰當(dāng)?shù)谋扔饕约笆聦?shí)2得出：95%同學(xué)們部門真的都沒有美女！

基于以上事實(shí)我們做一個(gè)假設(shè)：如果同學(xué)們部門里都是美女，大家一定都很開心！

基于這個(gè)假設(shè)得到事實(shí)3：都是美女的部門業(yè)績肯定完蛋了（這個(gè)推導(dǎo)過程只可意會(huì)不可言傳）。

根據(jù)以上一個(gè)假設(shè)和三個(gè)事實(shí)，我們得到結(jié)論：一個(gè)部門要有美女，但不能多！極端的工程師文化產(chǎn)生少數(shù)幾個(gè)極端成功的公司以及大多數(shù)死得很慘的公司。

工程師文化 vs KPI文化

• 工程師文化是由內(nèi)而外的引導(dǎo)和自然發(fā)生， KPI文化是由外而內(nèi)的信仰和強(qiáng)行注入。
• 工程師文化著眼未來， KPI文化活在當(dāng)下。
• 工程師文化痛恨KPI，我不愛的我不做，我愛的我瘋狂。 KPI文化唯KPI說話，愛不愛都要像戰(zhàn)士一樣完成。

[[234512]]

淺談工程師文化

工程師文化的前提條件

信任：leader和產(chǎn)品對工程師絕對的信任是工程師文化的最基本條件。如果他說要用一個(gè)更優(yōu)雅的方法解決一個(gè)問題，但要花更多的時(shí)間，請你選擇相信他。好的工程師非常懶惰，他這么做一定是為未來的工作提高效率。

卓越的技術(shù)***存在：領(lǐng)導(dǎo)如果對技術(shù)沒有信仰，只把技術(shù)當(dāng)成工具，就很難說這個(gè)團(tuán)隊(duì)會(huì)有工程師文化。說白了不是每個(gè)不懂技術(shù)的領(lǐng)導(dǎo)都懂得欣賞優(yōu)雅代碼產(chǎn)生的美和對未來產(chǎn)生的深遠(yuǎn)影響。

技術(shù)列為KPI：在我參加晉升面試的時(shí)候，50%以上的技術(shù)人員講的都是產(chǎn)品（what），而不是技術(shù)（how），并且他們都晉升了.....這源于業(yè)務(wù)BU總是把業(yè)務(wù)當(dāng)成KPI的唯一衡量手段：技術(shù)好不好有什么關(guān)系？今年不出事，明年我已晉升。如果沒有技術(shù)KPI，技術(shù)就會(huì)總被放在次優(yōu)先級。

工程師文化的特征

小團(tuán)隊(duì)：7-12人的團(tuán)隊(duì)是比較適合的團(tuán)隊(duì)大小。有人用pizza團(tuán)隊(duì)來形容一個(gè)團(tuán)隊(duì)的大小，就是一兩張pizza可以喂飽這支團(tuán)隊(duì)。facebook和google經(jīng)常有2-3個(gè)人的團(tuán)隊(duì)，小團(tuán)隊(duì)有如下特征（中文為個(gè)人即興翻譯，可以選擇忽略）：

• Move Fast and Break Things（不破不立）；
• Huge Impact with Small Teams（以少為多，精準(zhǔn)打擊）；
•  Be Bold and Innovative（勇敢追求卓越）；

技術(shù)創(chuàng)新：團(tuán)隊(duì)必須堅(jiān)信技術(shù)可以為業(yè)務(wù)帶來不同于現(xiàn)在的可能性，現(xiàn)在沒看見不代表它不存在。技術(shù)挑戰(zhàn)產(chǎn)品是因?yàn)橐苍S你不知道還有更好的技術(shù)和架構(gòu)可以更簡單更有效地完成一個(gè)業(yè)務(wù)任務(wù)。團(tuán)隊(duì)激勵(lì)不單純以業(yè)績?yōu)橹鞯募夹g(shù)的創(chuàng)新，比如：Google每個(gè)工程師都有20%的時(shí)間可以用于研究自己喜歡的技術(shù)，而不是跟Google相關(guān)的業(yè)務(wù)。

技術(shù)決策權(quán)大：尊重技術(shù)決策的前提就是信任技術(shù)決策，而不是簡單粗暴地說：“為什么完不成？隨便叫一個(gè)程序員就可以完成。”工程師未必在所有產(chǎn)品特性的定義上有決策的能力，但在優(yōu)先級和排期上是可以從技術(shù)角度給出決策。所有的業(yè)務(wù)deadline倒排都在一定程度上逼迫技術(shù)做出妥協(xié)，并且這些妥協(xié)慢慢變成合法理由：我的代碼不好的原因是業(yè)務(wù)壓力太大。Note：工程師們不要為自己邋遢的代碼找理由，代碼對于一個(gè)軟件工程師就是尊嚴(yán)。

技術(shù)數(shù)據(jù)可視化：可視化技術(shù)相關(guān)數(shù)據(jù)包含圈復(fù)雜度、測試覆蓋率、重復(fù)率等等，對數(shù)據(jù)好的工程師給予掌聲。但是，好數(shù)據(jù)給予的是掌聲而不是獎(jiǎng)金，所有數(shù)據(jù)都可以被造出來，這是個(gè)充分但不必要條件——好的代碼數(shù)據(jù)肯定好，數(shù)據(jù)好的代碼不一定是好代碼。

分享多會(huì)議少：寧愿少開會(huì)掰扯這個(gè)應(yīng)該誰做，這個(gè)P1應(yīng)該誰來背，也要多聽技術(shù)高手講一個(gè)技術(shù)細(xì)節(jié)，大家都應(yīng)該沉下心來沉淀一下自己的專業(yè)知識。

[[234513]]

敏捷

敏捷——一個(gè)飽受非議，飽受爭議的名詞。今天我提它不是想為它正名，其實(shí)是想說大個(gè)子女孩的故事：我有個(gè)大個(gè)子女孩同學(xué)，身材非常好，178cm，人到中年堅(jiān)持鍛煉，身材高挑，穿啥都是給啥做廣告。她告訴我，她外婆小時(shí)候走路只敢走在路坎的下面，鄰居朋友走在路坎上面，這樣可以顯得她外婆矮點(diǎn)。那時(shí)，高個(gè)的女孩是被嘲笑的：150cm的姑娘指著她外婆的背影說：“看這傻大個(gè)！”可今天我想對我同學(xué)說：“你女兒***也像你這么高，我兒子去看看能不能追上，優(yōu)化一下我家族的身高基因。”

很多人一聽到敏捷就說：“還說敏捷，早過時(shí)了！” 雖然今年流行網(wǎng)紅臉，不流行高個(gè)姑娘，可她就是比你高。那些聽到敏捷就嗤之以鼻的人，你們在堅(jiān)持什么？至少堅(jiān)持敏捷實(shí)踐的人心中有信仰，這是他們作為工程師的信仰，他們還在堅(jiān)持為減少一個(gè)if else修煉每一行代碼，堅(jiān)持為一個(gè)完整的自動(dòng)化測試不停思考，堅(jiān)持為了兩個(gè)模塊的解耦絞盡腦汁。

即便如此，今天不談敏捷，就像今天不談”身高“，我們談”身材修長“?；谶@個(gè)前提，敏捷還是不敏捷就不重要了：是不是敏捷，是不是所謂的工程師文化都不重要，重要的是找到適合團(tuán)隊(duì)的開發(fā)方式，讓團(tuán)隊(duì)開發(fā)效率更好，系統(tǒng)更健壯，特性更易擴(kuò)展。

盒馬基礎(chǔ)技術(shù)團(tuán)隊(duì)實(shí)踐

Note：本文，我僅對自己的個(gè)別兩個(gè)小分隊(duì)進(jìn)行描述。

設(shè)計(jì)

一個(gè)軟件技術(shù)團(tuán)隊(duì)的最終產(chǎn)出物是可交付的軟件本身，所以不管什么花里胡哨的管理方式都沒有一份安全和穩(wěn)定運(yùn)行的代碼來的給力。好的代碼應(yīng)該要有設(shè)計(jì)的痕跡：簡單粗暴地還原業(yè)務(wù)或多或少給未來埋坑。在我們團(tuán)隊(duì)，大部分微觀代碼設(shè)計(jì)源自我們自己定制的一套領(lǐng)域模型設(shè)計(jì)套路。套路里要有每個(gè)工程師對每個(gè)特性的精心設(shè)計(jì)，同學(xué)們的設(shè)計(jì)原則是：可以設(shè)計(jì)得不***，但不能不思考設(shè)計(jì)；即使已經(jīng)上線了的系統(tǒng)，只要有問題，代碼永遠(yuǎn)可以修改，但前提是有完善的自動(dòng)化測試保護(hù)。

自動(dòng)化測試

不要低估了自動(dòng)化測試可以給軟件質(zhì)量帶來的深遠(yuǎn)影響：不管是當(dāng)下質(zhì)量，還是未來加特性，或是單純的重構(gòu)代碼。

不要低估了編寫自動(dòng)化測試的難度：檢驗(yàn)代碼好壞的一條標(biāo)準(zhǔn)就是——是否很容易對這塊代碼添加有效的自動(dòng)化測試。

測試的一些原則：

• 代碼提交前通過所有測試：測試就是驗(yàn)收標(biāo)準(zhǔn)，是需求驗(yàn)收的代碼轉(zhuǎn)換。原則上一條驗(yàn)收標(biāo)準(zhǔn)可以對應(yīng)至少一個(gè)斷言（assert），沒有斷言的測試被視為無效測試；
• 用given／when／then語態(tài)寫單元測試；
• 要讓測試代碼更容易寫必須分離代碼邏輯與數(shù)據(jù)庫讀寫；
• 合理使用mock／stub技術(shù)，測你要測的，讓你的測試更有效；
• 異步測試不要用sleep；
• ***的debug手段就是測試；
• 單元測試耗時(shí)最短，多用單元測試覆蓋代碼邏輯；
• 越是集成測試數(shù)量應(yīng)該越少，因?yàn)榇鷥r(jià)很大，性價(jià)比不高；
• 靜態(tài)代碼質(zhì)量分析應(yīng)該伴隨每次持續(xù)集成。

持續(xù)集成/持續(xù)發(fā)布

持續(xù)集成其實(shí)什么都不是，它只是隨時(shí)把大家的代碼編譯、打包、部署、測試，不停地跑起來，持續(xù)地告訴你代碼質(zhì)量是否滿足你的測試要求：

• 測試應(yīng)按測試運(yùn)行時(shí)間長短分級編排在不同級別的持續(xù)集成中，時(shí)間短的測試應(yīng)該跑得更頻繁，比如：代碼的每一次push，時(shí)間長一點(diǎn)的跑的頻度低點(diǎn)，像是每隔3個(gè)小時(shí)，每天晚上11點(diǎn)開始......
•  一次編譯多次部署，在持續(xù)發(fā)布的環(huán)節(jié)中，只有***次編譯打包，后面的環(huán)境都是只部署不編譯打包。
• check in and pray vs check in and play： 每次提交代碼要有足夠的測試，并交給持續(xù)集成反饋結(jié)果，代碼提交越頻繁，你越容易play，代碼提交時(shí)間間隔越長，你越容易pray。
• 持續(xù)集成的反饋要立刻修復(fù)，別讓持續(xù)集成dashboard紅著。
• 持續(xù)發(fā)布是你的***目標(biāo)
• 開發(fā)分支要少，不然你的持續(xù)集成容易沒了方向，失去意義。

分支策略

我們采用的分支策略一定跟大部分同學(xué)們的分支策略背道而馳。

1. 大庫：大家都在一個(gè)庫上工作，理由不在這闡述了
2. 分支：分支盡量的少，分支越多持續(xù)集成越?jīng)]意義，merge成本越高，團(tuán)隊(duì)分支最多也不能超過下圖

結(jié)對編程

兩個(gè)人在一起寫代碼在阿里這么繁忙的企業(yè)應(yīng)該是件讓人匪夷所思的事情，但我堅(jiān)持讓團(tuán)隊(duì)踐行這個(gè)實(shí)踐：

• 一個(gè)主機(jī)，兩個(gè)鍵盤，一個(gè)顯示器
• 新老員工pair是新員工get實(shí)踐的最快手段
• pair讓員工有機(jī)會(huì)互相學(xué)習(xí)對方良好的編程方式，形成團(tuán)隊(duì)獨(dú)有的代碼風(fēng)格，而不是個(gè)人代碼風(fēng)格
• 時(shí)不時(shí)的pair不會(huì)降低開發(fā)效率，會(huì)提高學(xué)習(xí)熱情

[[234515]]

code review

很難說還有哪個(gè)實(shí)踐比這個(gè)實(shí)踐對代碼質(zhì)量更有意義，不過，大家codereview的方式不盡相同，我們的方式是：

• 團(tuán)隊(duì)code review，總共***1個(gè)小時(shí)左右
• 每天code review
• 每個(gè)人的代碼都要review，每個(gè)人都要講解
• 發(fā)現(xiàn)的問題當(dāng)天就改掉
• 看官們不要質(zhì)疑，因?yàn)檫@件事情真的每天在發(fā)生

standup站會(huì)

站會(huì)是團(tuán)隊(duì)溝通的重要手段，阿里其實(shí)大部分團(tuán)隊(duì)都有站會(huì)習(xí)慣。

• 不要超過15分鐘
• 一次只有一個(gè)人說話
• 只說三件事情：昨天干了什么，今天要干什么，需要什么幫助

technical session

不是每個(gè)session都跟業(yè)務(wù)相關(guān)，純技術(shù)的session是同學(xué)們提高技術(shù)的良好手段。

retrosepctive回顧會(huì)議

總結(jié)一下過去一個(gè)迭代做的好的和不好的，做出自己下一個(gè)迭代的改進(jìn)計(jì)劃。如果你覺得沒有用，仔細(xì)看看圖片里記錄的點(diǎn)點(diǎn)滴滴：

IPM迭代計(jì)劃

IPM計(jì)劃會(huì)議很有必要，團(tuán)隊(duì)可以借這個(gè)機(jī)會(huì)了解接下來兩周要做什么，大概誰負(fù)責(zé)什么，大概什么時(shí)候可以做完？

拜神

再好的方法也需要關(guān)公守護(hù)，廢話不說，把三兄弟都放上。

[[234517]]

IDE

永遠(yuǎn)不能忽略IDE對編程效率帶來的影響。IDE是工程師每天面對的工作環(huán)境，任何跟工程效率相關(guān)的思想都應(yīng)該以IDE PLUGIN的方式讓工程師們每天可用，每天受益。Intellij作為JAVA神器存在有其必要的原因是因?yàn)樗涯軒偷焦こ處煹拿恳粋€(gè)操作都簡化和方便到***。團(tuán)隊(duì)使用IDE的技能是否出神入化一定程度反映了這個(gè)團(tuán)隊(duì)的編程效率是否高。這是結(jié)對編程的另一個(gè)重要好處：一個(gè)團(tuán)隊(duì)使用同一套快捷鍵寫代碼，而這套快捷鍵是整個(gè)團(tuán)隊(duì)每個(gè)成員快捷鍵使用心得的合集。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文