2年前寫的工程師文化
謝東昇Forest，公衆號：架構棧說說我們的工程師文化
2年前，寫了一篇工程師文化，2年後，回過頭來看這篇文章，工程師文化對企業最大的價值之一（也許沒有之一）就是“工具解決問題”。
只有全面工具化，建立起槓桿的作用， 放大每個工程師的生產力。能用工具解決的問題， 就不要讓工程師上。
一個團隊基礎設施做的好不好的唯一標準，就是工程師離職去了另外一家公司以後，會不會懷念前團隊的工具：現在公司的工具沒有以前公司好用啊。
從產品開發生命週期來看每個環節都很重要，文檔管理、問題追蹤、代碼管理、持續集成、代碼質量檢查、移動APP打包、測試開發環境、部署上線、監控報警，選擇最適合自己團隊的。如果現有的產品都無法滿足需，求那麼我們就做二次開發。
敏捷
用了差不多10來年的Jira。 Jira 的好處是它功能強大可配置， 配套的 Confluence 等設施完善。每個產品線有自己的敏捷面板， 每兩週一次迭代，週一計劃會，下週五回顧會。 每天早上晨會，大家除了過一下昨天的進度和今天的計劃， 還會主要把一些小的疑問/困難放在晨會里說出來， 10 個人的晨會控制在15 分鐘內就結束了，這纔是我們要的效率。
什麼是迭代？其實迭代就是我們每天坐的地鐵，這個迭代能做完什麼就做完什麼。 車又不等人，做不完的等下一班地鐵唄。
版本控制
5年前在順豐的時候，用的版本控制工具是私有部署的 GitLab。 除了 Repository，還用上了裏面Merge Request/CI/CD/Wiki 等功能。
比如我們加一個新功能大概流程是這樣的：
fork 項目到本地開發
push 到自己的 repo，提一個 merge request
觸發了 CI 檢查
靜態工具檢查一波有沒有基本錯誤問題，比如沒有關閉連接、存在NPE問題等
版本工具檢查一下有沒有 migration 上的問題
跑完全部UT，看看單元測試能不能過
@ code owner 來 review 代碼
會有線上評論，不好解釋的線下1vs1
有問題就打回去修改，重新 push
approve + merge
自動觸發了自動構建
構建完成以後自動觸發了發版，發版完成
整個過程中 contributor 需要 fork + coding + merge request， code owner 需要 review + approve + merge， 剩下的單元測試、code構建、版本更新都是一條流水線做完。
監控
再舉一個幾年前自研的例子，當時公司的監控系統實際上使用好幾個開源組件加上自己的一些代碼粘合，監控系統統一了日誌格式、自動化了日誌收集、自動化創建監控模板，相當於任何一個新的（微）服務，在上線時就已經有了基本的監控圖表，想定製直接創建圖拖監控項上去，一個完整的 監控控制檯就有了。
寫在最後
所謂的工程師文化並不是高喊着口號，走走形式就可以讓所有人可以感受到的，是需要通過我們日常工作中持續地一點一滴來滲透，怎麼提升工程師的產出效率，那麼就這麼做。
描二維碼或手動搜索微信公衆號【架構棧】：ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓