“ 在技術團隊建立起技術導向的價值觀、良好的工程師文化，才能保持一個技術團隊的創新與活力。
洪強寧，EGO會員，目前籌備創業中。擁有十餘年網際網路從業經驗，資深Python程式設計師。曾任豆瓣網首席架構師與宜信大資料創新中心首席架構師。關注雲端計算、容器、微服務與安全技術。
我的經歷 先簡單介紹一下我自己的經歷，我2006年加入豆瓣，是豆瓣的第一位全職員工，從辦公室都沒有的狀態起步，經歷了團隊壯大的整個過程。一直到2014年離開豆瓣為止，我覺得豆瓣的技術文化是建立和保持得相當不錯的，是個典型的學習型團隊。
2014年我加入了宜信大資料創新中心，這也是一個技術氛圍濃厚的團隊，所有產品線的leader都是技術出身，在風格上和豆瓣相比更強調產出，產品推進速度非常快。
我會主要以豆瓣的情況為例來說明技術氛圍的建立和保持，也會穿插一些在宜信的做法。
技術導向 有技術導向的價值觀，是保持好的技術氛圍的最關鍵的事情。一個公司要想有較好的技術氛圍，首先從最高層開始就需要重視技術，尊重工程師。如果連CEO都認為工程師只不過是用來實現產品需求的資源，那麼技術團隊的負責人不管怎麼做，也不可能保持住技術氛圍的。
這裡說的尊重工程師，不是說給高薪之類的，而是說理解工程師的思維方式和做事方法，用客觀的、有邏輯性的方式來帶領團隊。比如重視資料、使用 A/B test 等方式來輔助決策、資訊公開透明、不隨意更改需求、開發週期主導權由工程師把握等。鼓勵工程師對產品發表意見甚至介入決策過程也是很好的實踐。
自上而下的推行技術平臺化建設、推行DevOps、推行自動化構建、測試和部署流程。這幾樣事情雖然不直接產出產品，但可以顯著提高團隊的開發效率和技術水平，以及能夠提升開發者為自己的產出物質量負責的意識，這也是一個好的技術團隊必要的素質。但是如果沒有管理者的大力支援，靠平級推廣，難度就要大很多。
在豆瓣的一個很好的實踐就是很早就建立了技術平臺團隊，這個團隊從被產品推著跑的重壓下解脫出來，專注於技術能力的升級和基礎元件的維護。因為有這個團隊的存在，各個產品線可以保持相似的技術棧和開發方式，在基礎元件升級換代的過程中也可以避免出現新舊版本混亂的情況。同時，由於脫離了產品壓力，這個團隊可以有更多的時間來考慮精益求精的技術問題，可以持續不斷的推動整個公司的技術氛圍。
管理者不斷向團隊提出更高的技術要求，提高技術挑戰度，可以促進技術氛圍。對於效能提升、對於成本控制、對於效率優化、對於運維友好度，這些技術要求會持續不斷的激勵團隊向更高的地方走，從而帶動整個團隊技術水平的不斷提升。
分享精神 分享是快速交流思想的一種手段。鼓勵分享可以使得技術討論的氣氛活躍起來，碰撞出新的想法，也能更容易讓優秀的人脫穎而出，成為團隊中的hero。
無論在豆瓣還是在宜信，我都會要求團隊成員每週輪流做一次技術分享，話題不限，但必須是技術相關。這是強制的，會迫使每個成員都意識到不能只滿足於完成工作內容，學習也是非常重要的。這可以使得團隊主動的去跟隨技術趨勢，同時一個人的研究方向可以在分享時傳達到團隊成員，形成討論，甚至直接可以應用到工作中。
除了這種比較重的強制分享機制，還需要為團隊成員提供輕量通暢的分享交流渠道，當任何人發現一個有點意思的資訊時，都可以沒有心理包袱的分享出來。在豆瓣我們用的是自建IRC，在宜信使用Slack和Bearychat。這種基於主題聚合的聊天頻道的設計，可以鼓勵交流，同時不會對正在專心工作的人產生干擾。
程式碼也需要分享，分享的手段就是 code review。早期豆瓣採用的是投影程式碼到牆上講解這種比較重的手段做 code review ，雖然由於效率問題只能 review 部分程式碼，但是所幸的是我們一直堅持了下來，並且不斷設法提高效率，嘗試了各種工具。在把程式碼倉庫從 svn 切換到 git 之後，幾乎所有團隊都立刻接受了 github flow 的工作方式，採用 pull request 作為 code review 的手段，迅速提高了 code review 的效率和流程通暢，基本可以做到覆蓋所有程式碼變更了。
code review 的好處非常多，對技術氛圍而言，最大的作用就是培養每個工程師對程式碼質量的追求。寫得很醜的程式碼在 review 時是會被無情抨擊的，在來來回回的 comment 的過程中，整個團隊對於什麼是好的程式碼會慢慢達成一致，大家也會以寫出好程式碼為榮。
多說一句，pull request 這種方式還有一個好處，就是打破團隊間的壁壘。每個團隊的程式碼都是公開的，如果你的工作需要別的團隊修改程式碼，你可以直接 fork 一份改完發 pull request 過去要求 review 。這對促進團隊間交流，提高跨團隊工作效率，避免大公司病是很有益處的。
上面說的都是內部分享，對外的分享包括公司間交流、技術大會分享、程式碼開源等等。這些相信大家都已經深刻理解了可以帶來的益處，就不多說了。
在一個工程師團隊內，榮譽激勵要比經濟激勵要有效的多，工程師最大的成就感就來自與自己的水平被同行認可。分享正是提供了榮譽感的來源。
鼓勵創新 對於架構師，在技術選型上有兩種傾向：偏保守或者偏激進。偏保守的，會多選擇已經經過多年使用，成熟穩定的技術，這樣不確定性因素少，掉坑機率小。偏激進的，會多選擇新出現的技術，因為新技術往往功能和效能上都更佳，可以更好更快的滿足需求。
兩種傾向各有優劣，我無意從技術層面上討論哪種更好。但如果要打造一個有濃厚技術氛圍的團隊，那麼最好是能將天平向激進一端傾斜一些。過於保守追求穩妥的技術團隊是很難形成學習型氛圍的。
在豆瓣，我們的傾向是非常偏向激進一邊的，幾乎對於新技術的引入是無保留的鼓勵。任何工程師希望引入一個新技術，除非看到明顯的問題（比如從現有技術無法平滑的切換過去），都會鼓勵工程師進行嘗試，用資料和效果來證明新技術的價值。一旦證明新技術可用且有效，就會進行全面的技術升級。嘗試失敗了，對工程師也不會有任何懲罰。
管理者對於創新需要有一個統一的認識：即創新都是有風險的。在豆瓣我們經常會說，多做才多錯，不錯是因為沒做。要避免的是沒有在錯誤中成長，而不是犯錯本身。
當然，對新技術的選擇會有一個硬限制，即團隊擁有徹底掌握它的能力，出現問題時可以深入到底層進行修復。這會導致語言傾向，即優先選擇使用本團隊熟悉的語言（在豆瓣是 Python ）編寫的元件。當然，如果一個其他語言編寫的元件非常有效，那麼在團隊內建設相應的語言能力，然後採納之，也是可行的。比如 Docker 技術的興起，我的建議是使用 Docker 的公司都應該擁有 Go 開發能力。
在招聘時，我們特別喜歡招聘喜歡“折騰”的人，即喜歡關注新技術，勇於嘗試，不畏懼失敗的人。這些人是真心喜歡技術的，團隊裡這樣的人一多，管理者再給予鼓勵，自下而上的創新就會自然而然多起來。
另外，舉辦或者參加 Hackathon 也是工程師釋放創新動力的一個途徑，Hackathon 往往更偏重產品層面的創新，這裡就不多說了。
工具文化 好的工程師是無法容忍低效的，能用技術解決的問題就堅決不要用人解決。所以要營造和保持一個好的技術氛圍，管理者就需要鼓勵使用工具，鼓勵工程師引入工具或者創造工具。
比如各種工作流，能夠使用系統線上解決的，就不要讓工程師拿著單子跑來跑去找人。能夠做事後稽核的，就不要做事前審批。能夠自動化的，就不要派個專人。繁瑣的流程一定會導致優秀人才的流失和責任感的退化。
比如技術文件，能用 git、wiki 或者 google docs 管理的，就不要用郵件發來發去了。
比如開發環境的建立，能夠做成一個一鍵建立的工具的，就不要再讓開發者對著文件到處下載安裝了。
比如軟體上線釋出，能夠做成一個釋出系統的，就不要再寫釋出文件交給運維一步一步操作了。
現在隨著雲端計算和SaaS的興起，有非常多的雲服務和第三方軟體可用，非常建議現在的管理者採購一些好用的工具，以及鼓勵工程師自研一些定製化的工具。在創造和使用工具上，工程師的熱情是高漲的，圍繞工具的討論也會促進技術氛圍的提升。
總結 要建立和維護好團隊的技術氛圍，需要自上而下的技術導向，需要成員之間的分享精神，需要鼓勵自下而上的創新，需要建立效率優先的工具文化。文化的建立和傳承是個潤物細無聲的過程，管理者自己需要真正認可技術文化，在工作中不斷打磨細節，才能起到效果。
有技術背景的管理者，對技術文化的認可一般不會有問題。但如果你的CEO或者合夥人還沒有形成這個認知，那麼不斷的影響他們，給他們灌輸技術文化的重要性，讓他們真正把技術重視在心裡而不是口頭上，這個可能其實是你最重要的工作之一。 若你想成為架構師，你可以加這個群獲取：交流學習群：744642380 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多 。