如何在團隊建設工程師文化？阿里資深技術專家這麼作

摘要： 人人都在說工程師文化，90%的同窗們嚮往工程師文化，然而95%的同窗們以爲本身的部門沒有工程師文化。但關於工程師文化，事實告訴咱們兩件事： 事實1是：咱們定義工程師文化的標準不同。這就跟美女同樣，每一個人心中的美女都不同, 但咱們都愛漂亮女。

人人都在說工程師文化，90%的同窗們嚮往工程師文化，然而95%的同窗們以爲本身的部門沒有工程師文化。但關於工程師文化，事實告訴咱們兩件事：

• 事實1是：咱們定義工程師文化的標準不同。這就跟美女同樣，每一個人心中的美女都不同, 但咱們都愛漂亮女。
• 事實2是：工程師文化仍是能夠客觀感受出來的。若是你真是個美女，你們仍是都會認爲你漂亮的。標準再不同，敢說奧黛麗赫本醜的人仍是須要莫大而且不要臉的勇氣。

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

基於以上事實咱們作一個假設：若是同窗們部門裏都是美女，你們必定都很開心！

基於這個假設獲得事實3：都是美女的部門業績確定完蛋了（這個推導過程只可意會不可言傳）。

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

工程師文化 vs KPI文化

• 工程師文化是由內而外的引導和天然發生， KPI文化是由外而內的信仰和強行注入。
• 工程師文化着眼將來， KPI文化活在當下。
• 工程師文化痛恨KPI，我不愛的我不作，我愛的我瘋狂。 KPI文化惟KPI說話，愛不愛都要像戰士同樣完成。

淺談工程師文化

工程師文化的前提條件

信任：leader和產品對工程師絕對的信任是工程師文化的最基本條件。若是他說要用一個更優雅的方法解決一個問題，但要花更多的時間，請你選擇相信他。好的工程師很是懶惰，他這麼作必定是爲將來的工做提升效率。

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

技術列爲KPI：在我參加晉升面試的時候，50%以上的技術人員講的都是產品（what），而不是技術（how），而且他們都晉升了.....這源於業務BU老是把業務當成KPI的惟一衡量手段：技術好很差有什麼關係？今年不出事，明年我已晉升。若是沒有技術KPI，技術就會總被放在次優先級。

工程師文化的特徵

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

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

技術創新：團隊必須堅信技術能夠爲業務帶來不一樣於如今的可能性，如今沒看見不表明它不存在。技術挑戰產品是由於也許你不知道還有更好的技術和架構能夠更簡單更有效地完成一個業務任務。團隊激勵不單純以業績爲主的技術的創新，好比：Google每一個工程師都有20%的時間能夠用於研究本身喜歡的技術，而不是跟Google相關的業務。

技術決策權大：尊重技術決策的前提就是信任技術決策，而不是簡單粗暴地說：「爲何完不成？隨便叫一個程序員就能夠完成。」工程師未必在全部產品特性的定義上有決策的能力，但在優先級和排期上是能夠從技術角度給出決策。全部的業務deadline倒排都在必定程度上逼迫技術作出妥協，而且這些妥協慢慢變成合法理由：個人代碼很差的緣由是業務壓力太大。Note：工程師們不要爲本身邋遢的代碼找理由，代碼對於一個軟件工程師就是尊嚴。

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

分享多會議少：寧願少開會掰扯這個應該誰作，這個P1應該誰來背，也要多聽技術高手講一個技術細節，你們都應該沉下心來沉澱一下本身的專業知識。

敏捷

敏捷——一個飽受非議，飽受爭議的名詞。今天我提它不是想爲它正名，實際上是想說大個子女孩的故事：我有個大個子女孩同窗，身材很是好，178cm，人到中年堅持鍛鍊，身材高挑，穿啥都是給啥作廣告。她告訴我，她外婆小時候走路只敢走在路坎的下面，鄰居朋友走在路坎上面，這樣能夠顯得她外婆矮點。那時，高個的女孩是被嘲笑的：150cm的姑娘指着她外婆的背影說：「看這傻大個！」可今天我想對我同窗說：「你女兒最好也像你這麼高，我兒子去看看能不能追上，優化一下我家族的身高基因。」

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

即使如此，今天不談敏捷，就像今天不談」身高「，咱們談」身材修長「。基於這個前提，敏捷仍是不敏捷就不重要了：是否是敏捷，是否是所謂的工程師文化都不重要，重要的是找到適合團隊的開發方式，讓團隊開發效率更好，系統更健壯，特性更易擴展。

盒馬基礎技術團隊實踐

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

設計

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

自動化測試

不要低估了自動化測試能夠給軟件質量帶來的深遠影響：無論是當下質量，仍是將來加特性，或是單純的重構代碼。

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

測試的一些原則：

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

持續集成/持續發佈

持續集成其實什麼都不是，它只是隨時把你們的代碼編譯、打包、部署、測試，不停地跑起來，持續地告訴你代碼質量是否知足你的測試要求：

• 測試應按測試運行時間長短分級編排在不一樣級別的持續集成中，時間短的測試應該跑得更頻繁，好比：代碼的每一次push，時間長一點的跑的頻度低點，像是每隔3個小時，天天晚上11點開始......
• 一次編譯屢次部署，在持續發佈的環節中，只有第一次編譯打包，後面的環境都是隻部署不編譯打包。
• check in and pray vs check in and play：
  每次提交代碼要有足夠的測試，並交給持續集成反饋結果，代碼提交越頻繁，你越容易play，代碼提交時間間隔越長，你越容易pray。
• 持續集成的反饋要馬上修復，別讓持續集成dashboard紅着。
• 持續發佈是你的終極目標
• 開發分支要少，否則你的持續集成容易沒了方向，失去意義。

分支策略

咱們採用的分支策略必定跟大部分同窗們的分支策略背道而馳。

大庫：你們都在一個庫上工做，理由不在這闡述了

分支：分支儘可能的少，分支越多持續集成越沒意義，merge成本越高，團隊分支最多也不能超過下圖

結對編程

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

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

code review

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

• 團隊code review，總共最好1個小時左右
• 天天code review
• 每一個人的代碼都要review，每一個人都要講解
• 發現的問題當天就改掉
• 看官們不要質疑，由於這件事情真的天天在發生

standup站會

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

• 不要超過15分鐘
• 一次只有一我的說話
• 只說三件事情：昨天干了什麼，今天要幹什麼，須要什麼幫助

technical session

不是每一個session都跟業務相關，純技術的session是同窗們提升技術的良好手段。

retrosepctive回顧會議

總結一下過去一個迭代作的好的和很差的，作出本身下一個迭代的改進計劃。若是你以爲沒有用，仔細看看圖片裏記錄的點點滴滴：

IPM迭代計劃

IPM計劃會議頗有必要，團隊能夠借這個機會了解接下來兩週要作什麼，大概誰負責什麼，大概何時能夠作完？

拜神

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

IDE

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

本文做者：輝子

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。