一年前的文，還是很受用，再發一次給這一年才加入的朋友參考。
討論串中還有提到 git-flow 的副作用 XD
—
這幾天把新竹敏捷之旅 workshop 大家用 C# 跟 php 寫完的 legacy code 重構了一番，包含測試的重構跟補全，重構的過程和手法也是精髓所在，不過重構過程的影片只開放給參與的朋友看，希望還有機會可以辦這樣的活動。
PS: php exp +2, 我很肯定我能用 php TDD 和 重構這個 kata 了。
分享一下 #PHP也有Day 社群, Miles 針對重構的簡報。
實戰、有趣，而且重構心法都是通的。
裡面其實就是對 Working Effectively with Legacy Code 這書的融會貫通，在實務上怎麼動手重構的手法。
--【補充 PHPConf 影片】--
https://youtu.be/yNYnLNAGq4k…
--
還有一個要點就是 branch 的策略。
上次去參加 Odd-e 的 ATDD/GOOS 開發課程時，講師 Jackson 提到，他們在顧問跟實務導入時，漸漸地都傾向不採用 git flow 的方式，透過 branch 來分開開發。
原因是 git flow 透過 branch 某種程度來說，是延遲持續整合（犧牲點），換取避免受到不同 feature 開發的干擾（效益點），把 merge 的時間點延後，要 merge 的量變大，誰晚提交，誰就負責承擔 merge 的 cost。
這其實就違背了持續整合的本質，無法在第一時間點發現整合上的問題。
當然，這是 for 開發的部分，針對部署的部分，該有的 branch 還是會拆分出來。
※ 開發的部分如果還是有不同 feature 得分階段上線的需求，那就是走 feature toggle 的方式。
--
不要因為 git flow 很常見很普遍，而忘了去思考有沒有其他改善的空間或方式。
--【補充】--
同場加映一下，跟這一份簡報類似的重構手法，來自 NetObjectives 的 design patterns wiki : http://www.netobjectives.com/PatternRepository/index.php…
其實這邊的 facade 跟簡報中的 proxy 有點類似，但手法不同。就看第一刀切下去的中間層粒度要到多粗多細囉。
#Refactoring
#LegacyCode
