相比5年或者10年前，對一個技術團隊而言，最大的變化就是工程效率得到了非常大的提升。無論是以Jenkins爲代表的持續集成的發展，還是以Selenium爲代表的各類自動化測試框架的脫穎而出，確實給我們日常的研發流程帶來了更多積極的變化。
我自己也做過一段時間的自動化，那麼今天我就簡單來說說我對自動化的理解。
用一句話來總結，自動化最主要目的是批量處理問題+批量發現問題。
比如我們要質檢1w輛待出廠的汽車，以前是人工一輛一輛地監測，現在是機器執行，那麼在1w輛車都沒問題的情況下，就節約出質檢1w輛車的人力時間可以去幹更重要的事情。
聽起來故事很美好，但是現實卻很骨感。
問題來了，如果這1w輛車有9999輛都監測出問題，還是不同類型的問題，這個時候，自動化的作用幾乎就微乎其微了，自動化和人工幾乎是一樣的，因爲定位分析問題+和人工溝通，這個是代碼做不了的事情，目前AI也做不了（等AI能做的時候，恭喜大家，都可以回家待業了）。
我舉這個例子，只想說明自動化是有前提的：
操作執行步驟相對標準
產品質量比較穩定。
否則一個團隊很難建立正常的自動化流程，尤其我們日常的產品迭代還這麼快。
工具和自動化是我們提升工程效率的方向，能簡單有效的提高效率，但也不要一上來就抱有過高的幻想，因爲在產品還不穩定的時候，效率瓶頸還是在需求的分析、架構設計還有業務邏輯的實現上，這些工作是沒法被自動化代替的。
想象下，你在自動部署上節約了半小時時間，怎麼也抵不上因爲需求沒分析清楚，導致一個功能需要重做而浪費的時間。
最後，說說我的結論：
1. 自動化必須是迅速漸進的，將穩定而且重複執行的日常事務分析出來，可以用自動化提升效率。
2 不斷分析其中實現成本低的，將實現後效果好的來歸入自動化的範疇，追求性價比高很重要。
3. 自動化或者工具化的長遠價值高於人工，但是要建立在合理的架構設計上，切記切記，不要用勤奮的自動化來掩飾架構設計上的懶惰。
描二維碼或手動搜索微信公衆號【架構棧】：ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓