[[409514]]

最近有些忙，就是給團隊里的同事寫的代碼進行工程化。 只是這些活對我而言有些過于體力活，我干起來提不起興致。

這個過程中也發現很多人不理解什么是“軟件工程化”。導致的結果就是，很少人知道我干的事的價值，也不知道該如何與我配合。所以，有必要正式給大家介紹一下我做的“軟件工程化”指的是什么。

要介紹軟件工程化，我們首先要從程序員寫出來的代碼開始說起。

首先，程序員寫出來的代碼，并不能直接運行。不同的編程語言，要運行起來，所經過的步驟不同，我們以Java來例。Java代碼運行起來需要以下幾個步驟：

1. 下載依賴 2. 編譯 3. 打包 4. 安裝運行環境，即JDK 5. 啟動程序

1,2,3步驟，我們通常稱為構建過程。Long long a ago，構建過程全在程序員自己的開發機上完成。后來，想偷懶的程序員發明了Ant這款工具，將構建過程自動化了。但是，Ant這款工具本質上只定義了一個基于任務的DSL（領域特定語言），不利于標準化。這時，Maven出現了。它將1,2,3步驟進行標準化。即，構建過程標準化。說多一句，在這方面，Gradle相對Maven其實是開了倒車。

構建過程，除了構建工具本身的標準化，我還會將構建環境標準化。這個過程就是根據不同的構建環境創建相應的標準化的Docker鏡像。將來，同一個項目的每一次構建都使用相同的構建環境。

構建過程的標準化只是軟件工程化的一個階段。下一個階段是構建過程自動化，即，將構建過程放到一個標準化的構建環境中自動化執行。換句話說，程序員依然在本地可以執行1,2,3步驟，只不過，團隊不再使用程序員本地構建出來的結果，而是使用標準化的構建環境中構建出來的。

在我做構建自動化的工作的時候，常有程序員不屑地說：我在本地電腦就一條命令，就可以把包上傳到制品倉庫了。

這樣的話，我聽了很多了。我想說：是的，你的確可以一條命令解決問題。但是你只是解決了你個人的問題。你并不沒有解決軟件團隊的問題。軟件工程化要解決的是一個團隊協作的問題，而是個人的問題。你的不屑就像當年在福特汽車廠里手工造車的工人，看不上流水線生產汽車。

在對構建過程工程化后，我們就開始對4,5步驟進行工程化了。4,5步驟叫做部署過程。部署過程的工程與構建過程的工程化類似，也是先標準化，然后自動化。

在沒有Docker之前，運行環境的準備和啟動程序的標準化是非常困難的，每個公司不一樣，同一個公司下的不同團隊也大概率不一樣。

有Docker之后，一切都變了。一下子任何語言的程序的部署過程的標準化都變得非常容易了。

在將原來的應用改成使用Docker運行的過程，是運行環境標準化的過程，也被我們稱之為容器化的過程。

它所帶來的好處是部署過程不用關心你的運行環境。也就是部署過程與軟件運行環境進行了解耦。

部署過程如何做到工程化，我之前的文章已經有說明，本文就不再細說。

這時，你發現，上面我們對1,2,3,4,5步驟做的，無非就是 把軟件生產工程中，體力的部分進行標準化，然后自動化。這就是軟件工程化 。關鍵是，你能否識別什么是體力部分，什么是腦力部分。

另，腦力部分，還是需要發揮每個人創造力。

最后，想想Kubernetes，其實它是軟件工程化的集大成者。它標準且自動化了軟件的構建、部署、可觀察性、軟件的運行方式。它真正做到了軟件的工程化。

個人經驗總結

• 標準化與自動化的順序并不是固定的。有時，你需要先自動化，再標準化。因為不自動化，沒有人力做標準化。
• 標準化涉及很多技術細節，在你還不了解何種標準更優時，千萬要先松后緊，不要一開始就把標準就定得全面且死板。標準是演化出來的。
• 部署過程的標準化，大多數人只記得對應用的部署，卻忘記了對配置也進行同樣的標準化部署。
• 工程化需要一個人知識面非常的廣，要懂多種語言、多種構建工具、多種部署工具、多種監控方式。