[[234511]]

前言

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

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

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

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

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

根據(jù)以上一個假設(shè)和三個事實，我們得到結(jié)論：一個部門要有美女，但不能多！極端的工程師文化產(chǎn)生少數(shù)幾個極端成功的公司以及大多數(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)品對工程師絕對的信任是工程師文化的最基本條件。如果他說要用一個更優(yōu)雅的方法解決一個問題，但要花更多的時間，請你選擇相信他。好的工程師非常懶惰，他這么做一定是為未來的工作提高效率。

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

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

工程師文化的特征

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

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

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

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

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

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

[[234513]]

敏捷

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

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

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

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

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

設(shè)計

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

自動化測試

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

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

測試的一些原則：

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

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

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

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

分支策略

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

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

結(jié)對編程

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

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

[[234515]]

code review

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

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

standup站會

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

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

technical session

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

retrosepctive回顧會議

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

IPM迭代計劃

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

拜神

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

[[234517]]

IDE

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

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

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