筆記：Introducing Branch By Abstraction
來源： http://paulhammant.com/blog/branch_by_abstraction.html 接下來就看看Branch By Abstraction有多厲害，實際看下來，的確是一套很有用的方法，簡單來說，就是把整合的工分散到每日的開發中。但是要實行有一些現實的問題需要克服 當我要新加一個Feature，會改動3個Class，這3個Class可能所有Module都要參考，而且與其它Module的Code綁很緊，要抽成Abstraction要改動的地方也是會很多，根本就是翻了。 就算我做好抽象層，把所有Module參考到這三個Class的地方改為呼叫抽象層，這樣還是對Code有變動，也是有可能對產品造成衝擊。 如果這3個Class的修改連介面都換掉，整個Class改頭換面，煥然一新，原來的使用流程已經不在，就算有抽象層當緩衝，還是免不了對產品造成衝擊。 這些現實的問題，我想是可以克服的，第一就是要有完整的Test，Unit Test，Integration Test，UI Test，但是如果Test不夠完整，可以使用這招嗎？我想答案是肯定的，但是要邊做邊補Test。而沒有任何Feature Branch，大家都只看Trunk，也就是mainline，這件事對目前的我而言，簡直就是美麗的夢境！我自己參與的產品就有遇到這種狀況，目前是分支一個Branch來做，如果用Branch By Abstraction，新的東西就可以不用等好幾個版本之後才進mainline，也不用擔心如果合併回mainline，到底會是怎麼樣的地獄。如果我有機會參與決策，我一定直接就這麼搞。 另一點作者提到除了Release之外，完全沒有其它Branch，這點我還是有點存疑，除非有一套機制讓Developer拿著Commit去取得認證，保證不會Break掉任何東西。不然Developer自己一個人做測試還是有限，如何保證不Break mainline？如果一個產品的開發編制如下： 100個Developer 分成15個Team，有的Team人多，有的Team人少 25個Component，從Web UI，Mobile UI，Database，Domain，Infranstructure..... 有跨Component，跨Team修...