軟件開發中，多人協作是一個常見的場景，如何來協作管理不同開發人員開發的代碼變成重中之重，因此 CVS 等版本管理工具也應運而生。現如今，Git 已經佔據了版本管理的主導地位。基於版本控制出現了一系列的開發模式，用以幫助團隊更加快速地協作。本文中，作者從他的實踐，全面的展示了主幹開發的模式在開發中應用的優勢，希望能給你的工作帶來更高的效率。
作者 | Tylor Borgeson，已獲作者翻譯授權
譯者 | 羅昭成
原文 | You don’t need Feature Branches anymore…
本文首發於 CSDN 微信（ID：CSDNnews）
1. 寫在前面
這是我「流行軟件開發實踐」系列文章中的第三部分，在本系列文章中，我計劃包含軟件工程師通過提升開發流程和實踐來改善軟件開發的一系列方法。我曾在 ThoughtWorks 擔任軟件顧問，現在我在德國一家大型的零售公司工作，這些方法都是我在職業生涯中學習並實踐驗證過的。
在我的職業生涯中，我一直在做一件事，倡導着能讓開發團隊提效的實踐，當然，我也花了很多時間去嘗試這些實踐。
在這些實踐中，有一個是我非常喜歡的主題，主幹開發 （TBD）。有意思的是，和測試驅動開發一樣，它也受到了很多高級軟件開發者的反對。
在軟件開發過程中，有很多刻板印象，並且很多軟件開發者深受其害。而主幹開發的思想直接與那些刻板印象直接開戰，這也是我喜歡它的原因。
在外人看來，IT 行業中的軟件開發者就像是 “神話中的人物” 一樣，這些開發者們頭帶着耳機，用 3 到 4 個顯示器，他們的顯示器上永遠是黑色的窗口，並跳動着綠色的字符，當他們接到一個任務時，會在一個暗黑的環境下，很快的完成任務，做到一般人想都不敢想的事情。在幾年前，只有 19 歲 Rumor，花了一週時間編寫了 2048 遊戲，僅兩週時間就有超過 1 億用戶。就是這些事件，讓很多人都覺得開發者無所不能。
這些程序員的故事在大衆之中流傳，給程序員帶上了光環，雖然，這些光環讓程序員很酷。但是，這些光環只會給團隊在軟件開發上帶來負面影響。
如果團隊中存在帶着光環的程序員，那這種基於主幹開發的形式基本不能被實現。基於主幹開發的模式需要團隊合作，團隊人員都要有同理心、並且開放。所以，在團隊中最好不要有個人主義很強的人，那樣子極不利於協作。
2. 什麼是基於主幹開發？
基於主幹開發（TBD）是一個軟件開發的流程，trunkbaseddevelopment.com （網站中有非常多關於 TBD 的資料）網站中有如下定義：
在版本控制的分支模型中，開發人員都在同一個被稱爲“主幹“的分支中進行協作，多個開發人員的代碼的匯聚在一起，從而避免創建長時間無法合併分支。因此，這種方式避免了合併地獄，也不會破壞構建，並從此讓開發人員過上幸福的生活。
這個觀點強調，我們不應該爲新的功能創建分支，也不要讓代碼在分支中開發完成後才合併到主幹上。我們應該把新功能拆分出很多小的塊來實現，並且在每一塊完成的時候都將它推送到主幹中去。
換句話說，項目組成員在開發的過程中，不應該使用任何分支。
我知道，對於任何一個工作過一段時間的開發者來說，將代碼”直接推到主幹“都是非常激進的做法，都會不由自主的抵制 TBD 的想法。但是我希望，你能繼續往下看，我會在本文中，盡我所能，解決你的疑問。
3. 爲什麼 TBD 重要？
我不得不再次提到敏捷開發中定義的衡量軟件開發有四個關鍵指標，因爲他們真的很重要。在書中，這樣寫道：
我們研究過在成功技術改造中都具有的實踐，他們包含版本控制，自動化部署，持續集成，主幹開發以及低耦合架構。
這些實踐不僅僅是重要，而是必須。之前，我寫過關於持續集成的文章，基於主幹開發也是其中的一部分。
基於主幹開發中，除了可以讓提交代碼塊變小，減少合併衝突，它還能在以下幾個方面有較大提升：
- 部署頻率和故障平均恢復時間
TBD 與 CI/CD 進行配合使用，完成功能的代碼都會經過測試，這些測試爲”綠色“的代碼會被髮布到生產環境上。每一個更改都推送到主分支上，這意味着會有大量的集成和部署。在我的團隊裏面，每天大概會發布 30~40 次。提高部署頻率是敏捷開發四個關鍵指標中的第二個。
我記得曾經在我的團隊發生過這樣子的事情，有一個”用來展示屬性列表“的簡單的前端頁面，我們把這個頁面發佈上線，但是在代碼中缺少了 Null 和 undefined 的檢查，最後導致前端出現了錯誤。
當然，這種錯誤的出現與使用哪種開發模式並沒有關係。但是，如果使用主幹開發，我們可以在 5 分鐘內編寫測試並修復這個 Bug，並將新的版本發佈到生產環境中。平均故障恢復時間是敏捷開發四個關鍵指標中的第三個。
這種基於主幹開發的模式，與 CI/CD 結合，能夠快速幫助團隊發現問題，並在處理問題時使用”前滾“的方式，而不是”回滾“。
- 代碼質量與知識共享
在 TBD 的模式中，代碼會被直接提交到主幹上，通常情況下，大多數人都會覺得，這樣子做，代碼庫中的代碼質量會受到影響，並且錯誤的可能性也會上升。我的觀點與之相反，TBD 不僅可以提高代碼質量，也能使程序的魯棒性更強。
我們來看下面這個場景，團隊中使用分支開發，並且使用 pull-request 的方法來進行代碼合併。當功能開發完成時，開發人員需要發起一個 pull-request 請求。而團隊中的其他人員需要查看並評論另一個開發人員花費數小時完成的代碼，這是一個多麼痛苦的過程，並且不一定能發現其中的問題。
但對於 TBD 來說，因爲沒有了分支，也就意味着沒有 pull-request，也不需要安排高級開發人員進行代碼審覈。對於大多數團隊來說，只要遵循”四眼原則“就行了，即至少有兩個開發人員查看並批准代碼進行入主分支。
我的團隊中，我們使用結對編程的方式來實現”四眼原則“，一切都運行良好。在 TBD 中，沒有了 pull-request, 結對編程變得很有必要。兩個開發人員一起解決問題比一個開發人員單獨工作時要好很多。每個開發人員都有不同的技術棧和不同程度的經驗，結對編程也可以讓開發者向隊友學習。
想像一下，當一個初級工程師與一個高級工程師協作時，團隊的代碼規範能夠在最短的時間進行傳遞，代碼設計也可以在開發初期被糾正，而不是在開發完成後在進行反饋。兩人一起寫代碼，也標識着他們都知道代碼是如何運行的。
- 協同
結對編程是團隊協作中的一種模式。TBD 的模式在團隊協作中，能提高團隊成員的同理心，讓團隊成員更好的協作在一起。
對於一個在行業中從業多年的開發者來說，在沒有看到代碼之前，就將一個新手寫的代碼合到主幹上，這是一件非常有挑戰的事情。但是作爲隊友，我們要相信我們的夥伴，在沒有別人幫助時，也能夠勝任相應的工作。對一個團隊來說，信任非常的重要。
高級工程師都很聰明並且大多數都有豐富的經驗，但是，你要相信，團隊其它人也是非常聰明的。你可以讓經驗豐富的程序員評審新手的代碼，提升代碼的質量。當然，你也可以使用結對編程的方式，並且過不了多久，你就會發現，即使是新手，也能寫出非常優秀的代碼。
4. 潛在的挑戰
- 沒有完成的新功能
沒有人願意將沒有完成的新功能（如一個沒有實現功能的按鈕）發佈到生產環境中給用戶使用。爲了解決這個問題，我們可以使用新功能開關，在新功能沒有開發完成之前，這個開關一直保持關閉，這些新的功能將會被隱藏。當新功能開發完成，測試通過後，在將開關打開或者將開關移除。不僅如此，還可以使用這個開關來做 A/B 測試。
- 測試與監控
主幹開發需要團隊有一個很強的測試套件，並且有一個好的監控器，能夠在出現錯誤的時候，及時通知到開發人員。越快的反饋循環越好。CI/CD 中阻塞的問題需要第一時間處理，防止其它成員獲取有問題的代碼，影響他們的開發。
爲了防止這種阻塞的問題，我們可以將代碼功能拆分成儘可能小的提交，並且儘可能使你的開發環境與與測試、生產環境類似，並且在每一次提交之前，都運行一下那些管道任務。
5. 寫在最後
我知道，已經有很多團隊，如文中所述一樣，實現了基於主幹開發的模式，這些團隊都沒有在切回原來的 Pull Request 的模式。還有一些團隊是因爲其它原因，切換到主幹開發的模式，例如團隊需要使用結對編程。
軟件開發和生活一樣，同一件事情並不一定適合所有的人。最重要的是，我們要找到適合自己團隊的模式。我曾經就遇到過這樣子一個例子，團隊中的人數爲基數，這就表示他們沒有辦法在所有任務上都分配兩個人進行結對開發，這導致他們在任務分配上”心力交瘁“。在這種情況下，他們採用分支開發，並每天合併一次，另人喫驚的是，這和主幹開發非常類似。
下一步，嘗試基於主幹開發，並按照你們團隊的情況，進行調整，找到最適合你們團隊的模式。