[[234511]]

前言

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

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

基于這個不恰當的比喻以及事實1得出：90%同學們都愛美女；基于這個不恰當的比喻以及事實2得出：95%同學們部門真的都沒有美女！

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

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

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

工程師文化 vs KPI文化

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

[[234512]]

淺談工程師文化

工程師文化的前提條件

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

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

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

工程師文化的特征

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

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

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

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

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

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

[[234513]]

敏捷

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

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

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

盒馬基礎技術團隊實踐

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

設計

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

自動化測試

不要低估了自動化測試可以給軟件質量帶來的深遠影響：不管是當下質量，還是未來加特性，或是單純的重構代碼。

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

測試的一些原則：

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

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

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

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

分支策略

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

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

結對編程

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

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

[[234515]]

code review

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

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

standup站會

站會是團隊溝通的重要手段，阿里其實大部分團隊都有站會習慣。

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

technical session

不是每個session都跟業(yè)務相關，純技術的session是同學們提高技術的良好手段。

retrosepctive回顧會議

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

IPM迭代計劃

IPM計劃會議很有必要，團隊可以借這個機會了解接下來兩周要做什么，大概誰負責什么，大概什么時候可以做完？

拜神

再好的方法也需要關公守護，廢話不說，把三兄弟都放上。

[[234517]]

IDE

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

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

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