優化您的“內部開發循環”以提高開發速度
關鍵在于找到本地開發速度和容器優勢之間的平衡，而使用合適的工具和實踐，這是可以實現的。
譯自Optimize Your 'Inner Dev Loop' to Increase Developer Velocity，作者 Matt Voget。
就像每個流行文化都有一個辛普森一家笑話一樣，科技界的一切都有一個 XKCD 漫畫。一個很好的例子是“編譯,”，來自 2007 年。
十七年后，編譯已經有點不受歡迎了。但我們都知道這張漫畫現在會說什么：“我的代碼正在容器化。”
容器化在擴展開發方面發揮了重要作用。它允許開發人員在開發的不同階段以及從本地機器到生產服務器創建一致的環境。
這種一致性消除了古老的“在我的機器上可以運行”問題，并顯著減少了與配置相關的問題。
但它也帶來了新的問題。容器構建和注冊表上傳對工程師來說純粹是停機時間。
容器化可能很慢，這會影響生產力。這種稅收通常用于運行和測試代碼，然后在代碼發生更改時再次支付。你可以看到由此展開的問題。
圖片
情況并非總是如此。在沒有容器的情況下，傳統的開發循環更快，允許更高的速度和更多的迭代。
我們能否在不犧牲容器優勢的情況下恢復這種速度？可以。
內部和外部開發循環解釋
這里的問題在于“內部開發循環”。內部開發循環是開發人員在本地工作于功能或錯誤修復時執行的一系列活動。它通常包括：
- 編寫或修改代碼
- 構建應用程序
- 運行和測試更改
- 必要時調試
- 提交代碼
這個循環在一天中重復進行，其效率極大地影響了開發人員的生產力。這個循環越快越流暢，開發人員可以進行的迭代次數就越多，從而更快地解決問題和開發功能。
相比之下，“外部開發循環”涵蓋了更廣泛的開發生命周期，包括：
- 規劃和任務分配
- 代碼審查和協作
- 持續集成和部署
- 暫存和生產發布
- 監控和反饋收集
容器化的優勢通過確保環境一致性和簡化部署而累積到外部開發循環中。但它給內部開發循環帶來了摩擦。構建容器并等待它們啟動所花費的時間會降低開發人員高效編碼所需的迭代速度。
在容器化之前，內部開發循環可能看起來像這樣：
圖片
因此，在傳統的內部開發循環中，我們每次開發迭代只需 5 分多鐘，只有 10 秒的“稅收”停機時間。回顧容器化版本，這延長到了 9 分多鐘，其中近一半是“稅收”。
如果開發人員每天編碼 6 個小時，我們從容器化遷移到容器化后，迭代次數從 70 次減少到 40 次。在為期兩周的沖刺中，這將損失 300 個循環。
因此，優化容器化環境中的內部開發循環對于保持高開發速度至關重要。
降低內部開發循環的停機時間稅
在容器化環境中簡化內部開發循環是奪回失去速度的關鍵。我們必須找到方法來最大限度地減少容器化和部署帶來的“稅收”，同時保留容器提供的一致性和可移植性優勢。現代工具和實踐在這里發揮作用。
一種越來越流行的方法是本地到遠程開發。這種方法允許開發人員在本地運行代碼，同時無縫連接到遠程 Kubernetes 集群。像 Ambassador 的Telepresence這樣的工具使開發人員能夠像本地機器是遠程集群的一部分一樣進行編碼。
這個想法很簡單但很強大：開發人員無需為每次代碼更改構建和部署容器，而是可以在本地運行一個正在開發的服務，并使其實時與遠程集群中的其他服務交互。這種方法提供了幾個優勢：
- 更快的反饋循環：開發人員可以立即看到其更改的影響，而無需等待其完整應用程序容器化和部署。
- 熟悉的本地開發：工程師可以使用他們喜歡的工具和 IDE 來保持生產力。
- 訪問遠程資源：開發人員可以像訪問本地資源一樣與遠程集群中的數據庫、微服務和其他資源進行交互。
- 減少資源使用：需要更少的遠程開發環境，這可能導致成本節省。
- 協作開發：由于個人攔截等功能，團隊可以在同一個集群上同時工作，而不會互相干擾。
采用這些工具和實踐可以顯著減少內部開發循環的“稅收”。讓我們用這種優化方法重新審視我們之前的示例：
圖片
在這種優化方案中，我們將迭代時間縮短到大約 6 分鐘，只有大約 30 秒的停機時間稅。這意味著在 6 小時的編碼時間內大約可以進行 60 次迭代——這比容器化版本有了實質性的改進，并且更接近我們最初的預容器速度。如上所示，使用本地測試，開發人員循環比傳統循環略長，但仍然比常規容器循環快得多，并且它包含容器化的優勢。雙贏！
目標不是放棄容器——它們在擴展和生產方面的優勢太寶貴了。相反，混合方法可以將本地開發的速度與容器化環境的一致性和可靠性相結合。
通過專注于優化內部開發循環，我們可以幫助開發人員恢復他們失去的速度，從而導致更多迭代、更快的功能開發，以及最終更快地獲得更好的軟件。關鍵是找到本地開發速度與容器化優勢之間的平衡——有了合適的工具和實踐，這種平衡是可以實現的。
最終，您的開發過程可以如此流暢，以至于您甚至沒有時間在容器化時查看 XKCD。
