程式設計師為什麼千萬不要瞎努力？

CSDN資訊發表於2020-03-23

程式設計師為什麼千萬不要瞎努力？

本文作者用對比非常鮮明的兩個開發團隊的故事，講解了敏捷開發之道 —— 如果你的團隊缺乏統一標準的環境，那麼即使勤勞努力，不僅會極其耗時而且成果甚微，使用容器化技術、CI/CD，不僅能讓開發環境、測試環境、預發環境、生產環境保持一致，同時也對測試和質量保證有至關重要的作用。

程式設計師為什麼千萬不要瞎努力？

作者 | Tylor Borgeson，已獲作者翻譯授權

譯者 | 羅昭成，責編 | 唐小引

頭圖 | CSDN 下載自東方 IC

出品 | CSDN（ID：CSDNnews）

以下為譯文：

程式設計師為什麼千萬不要瞎努力？

這是我「流行軟體開發實踐」系列文章中的第四部分，在本系列文章中，我計劃包含軟體工程師通過提升開發流程和實踐來改善軟體開發的一系列方法。我曾在 ThoughtWorks 擔任軟體顧問，現在我在德國一家大型的零售公司工作，這些方法都是我在職業生涯中學習並實踐驗證過的。

程式設計師為什麼千萬不要瞎努力？

這麼多年來，我參加過很多團隊活動，如足球、棒球、摔跤、籃球、足球、田徑……我基本上參加了所有與運動有關的團隊活動。有趣的是，我也加入過很多軟體開發團隊。

在這些團隊中，我注意到了一個共同點，優秀的人才可以為團隊成功中做出重要的貢獻（如贏得比賽，高效開發需求並上線），但是他們並非團隊成功唯一的原因。

在運動專案中，訓練很重要，但是並不是所有的訓練都重要。真正有用的那些訓練是那些看起來不像是訓練的訓練。所以，對運動專案來說，比賽才是最好的訓練，對於軟體開發來說，在和生產環境幾乎一致的地方測試才是有效的。

這個觀點也是本文的重點，在和生產環境一樣的環境中，進行開發和測試的效果非凡。下面，我將用兩個我以前所呆過的團隊中的故事，來闡述這一觀點。

勤勞有限責任技術公司 —— 團隊一

這個公司名稱是虛構的，但是團隊的工作情況和公司名字一致。

公司中有一個很大的前端專案，很多團隊都在上面貢獻這自己的努力，當然，我們團隊也寫著其中一部分功能。這些團隊各自提供著自己的服務，並且這些服務也存在著各種相互依賴的關係。

當第一天到公司的時候，我們不得不在自己的新電腦上設定基礎的開發環境。這些環境不僅僅包含我們部門自己的依賴服務，還必須要包含很多其它部門需要依賴的服務。這就導致我很難在本地將整個應用程式跑起來。

經過我的努力，我花費了兩天時間，終於在我的電腦上跑起了整個應用程式例項。但據我所知，很多其他的程式設計師並沒有將本地環境跑起來，而是與其他人進行結對程式設計，共用同一個環境。

很多同事都不能在本地測試他們的程式碼，這就意味著，他們需要將他們的修改釋出到測試環境中去，才能知道他們修改是否能夠生效，是否能夠正常地與其它服務進行互動。

這在實際工作中，具有相當大的挑戰，很多團隊並不能及時將所有的程式碼更改推送到所有的環境中去。這將會有可能出現在測試環境中的測試結果與生產環境的結果不一致。

有一次，我們部門的一個程式設計師對一個功能進行修改，該功能需要與另外一個部門提供的服務進行資料交換，他很快就開發完成了，並在測試環境中進行測試，但在測試環境中，一直無法正常的跑通。但當我們把修改釋出到線上環境，卻發現能良好地執行起來。最後排查到問題原因是因為在測試環境與線上環境依賴的服務版本不一致。線上環境使用的是一個新版本（5.0.2），而測試環境卻是使用的一箇舊版本（5.0.1）。

另外一件“有趣”的事是，我們的測試環境是一臺虛擬機器，當需要更新程式碼的時候，我們需要登入到那臺機器，在上面跑一個指令碼，將最新的程式碼拉到伺服器上，並重啟應用。並且，公司的虛擬機器數量不足以提供給每一位開發者使用。

這些問題，也導致程式碼部署到生產環境的過程非常漫長。所以為了減少部署所花費的時間，所以我們會每兩週在生產環境中（像測試環境那樣）進行一次部署。當然，每當有新東西（新功能、Bug 修復等）要釋出到生產環境中時，都需要重複一次這個耗時的部署過程。

聰明有限責任技術公司 —— 團隊二

顯然，這個公司名稱也是虛構的，但是其團隊的工作情況和公司名字一致。

就整個團隊而言，這個團隊和前文所述的團隊幾乎一致。我們也致力於多個微服務[1]的開發，我們也需要和其它做著類似事情的部門進行互動。我們通過 REST 介面接收請求，也傳送請求到其他服務上。

當第一天到公司的時候，我再次開始設定我的基礎開發環境。在程式碼庫中的 README.md 檔案中，列出了配置開發環境的幾項說明：

安裝 Docker；
如何從團隊映象庫拉取和推送 Docker 映象；
如何在本地執行容器；
如何將本地修改關聯到容器中。

從我拿到專案許可權，一個半小時後，我在本地跑起來了第一個服務，並且能夠將本地的改動推送到這個服務上。

這個團隊和前文所述的那個團隊一樣，也有測試環境、預發環境、生產環境。一旦程式碼提交到主幹上，CI/CD[2]上的任務會自動將程式碼構建成 Docker 映象，並開始跑測試用例，緊接著會給映象打上版本和標籤並將映象推送到映象庫中，還會將測試環境與預發環境中的映象替換成最新的版本。在必要的時候，通過手動觸發，將映象部署到生產環境。

整個過程，在最糟糕的一天，也最多花費 10 分鐘時間。

在這個公司中，所有的團隊都有類似的設定。

這些環境的區別在於，在測試環境中，使用的是測試資料，第三方的服務要麼是被忽略掉，要麼是被 mock 掉。在預發環境中，也是使用測試資料，但是其它的服務都是在正常執行狀態。