Trunk Based Developement 概述

Trunk Based Development

最近看到了google 的一些文章，裡面提到了google & facebook 都使用了Trunk Based Development，覺得很有趣，所有就去查了一些相關的文章
Trunk Based Development最特別的地方就是，新的功能並不是開一個新的feature branch做開發，而是直接在trunk 上做開發，當然依然要遵守，每筆commit都不能太過於龐大的守則

由於Trunk Based Development 會使多個功能同時在同一個branch上開發，這也就衍生了另一個問題，假設某些功能是v1.0要進，某些功能是v1.1才要進，那要怎麼處理?

根據martin fowler的說法，我們必須實作feature toogle，講白了點就是類似開關的功能，根據設定檔開啟或關閉該功能，舉個例子來說，某個版本要進v1.1，但是我們的功能在v0.1 的時候就已經開始開發，所以我們必須實作一個開關，避免v1.0的版本會出現這個不應該出現的功能，接著我們可以在v1.1的時候將開關打開，然後在v1.2的時候將開關這個功能拔除並且移除舊的功能.
又或者，我們可以實作branch by abstraction的方法，其實也是一個開關的概念或者是說switch的概念，當沒有切換的時候就使用舊版的作法，當切換的時候則改成新版的做法，至於為什麼要使用abstraction的關鍵字?
其實這也對應到了 OO的概念

針對介面來撰寫程式，而不要針對實作

所以在實作這個功能的時候，首先必須先將共同的邏輯抽離抽成interface or abstract，然後舊版則實作這個interface or abstract，新版也實作這個interface or abstract，然後最重要的是使用者只針對interface or abstract 做動作，然後我們就可以去做switch的動作

TBD的好處

• 降低test的成本
  
  • 如果有多個feature branch也就代表有多個branch要執行test，這相對也提升了test 成本
• always是可以release 的codebase，並且可以根據需求，修改需要release的功能
  
  • 可以利用開關開啟或關閉某項功能
  • 可以利用開關使用新版或舊版功能
• 減少merge conflict的機會
  
  • 由於所有人都在同一個trunk上開發，只要所有的人都保證commit的code並不是過於龐大，就算遇到conflict也可以快速解決
  • 適合多人同時開發的專案

結論

講了那麼多，其實我也還沒有機會實際run過這個流程，不過根據目前的理解，TBD講白了就是把所有的功能都放在同一個branch上開發，然後使用featuretoggle & branch by abstraction來隔開尚未完成的實作，很合理…但是同時也覺得會有很多坑啊!!

reference

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/
http://martinfowler.com/bliki/FeatureBranch.html
http://www.martinfowler.com/bliki/FeatureToggle.html
http://paulhammant.com/blog/branch_by_abstraction.html

敏捷開發(二) 站立會議

在敏捷開發中，站立會議是每天必開的會議，
對許多人來說"開會"是個非常可怕的事情，隨便一個議程就要一個小時跑不掉，
對許多人而言會議跟浪費時間掛上等。

然而對我而言，以前開會的確是很浪費時間，但是現在身在敏捷開發中，每一次會議都讓我感到非常的珍貴，其中一項就是站立會議。


甚麼是站立會議

站立會議顧名思義，就是站著開會，其實第一次開會的時候覺得很有趣，
感覺像是一堆人在那邊罰站，然後就從第一位開始一個接著一個報告，
內容基本上都是

昨天我做了甚麼，有沒有遇到甚麼問題，今天我打算做甚麼。
如果是小問題就拿出來大家稍為提供一些意見，沒有問題的話就換下一位



為何要站立會議

站立會議的目的就是讓其他人瞭解每個人目前的進度(尤其是PM)，
然後有哪些人目前是比較有空閒，以便於做其他的安排，例如假設小明昨天完成了一項功能，今天沒其他的事情就可以派去幫忙解bug或者refactor，簡單來說這樣可以讓PM對於人力做較適當的安排。



站立會議的時程

我們參加會議的人數大約十個，但是會議時間通常不會超過十五分鐘，
通常都是兩三句話就帶過，如果有其他的問題通常會找幾個相關人員私下討論。



敏捷開發 = RD會變輕鬆?

站立會議讓大家互相了解目前的進度，其實對RD而言也是一種壓力，
假設兩個人負責相同的功能只是負責的平台不同，例如android 版 vs ios 版
假設一個人接近完成，另一個人還有一半功能尚未完成，這時候壓力就大了，
雖然說RD可自行訂定任務完成的時間，但是天有不測風雲，總是會有無法預測的事情會發生，個人認為敏捷開發需要有非常高的自主性，必須對做的事情負責，知道自己的不足就必須自己補足，進而追上平均的速率，然後關於寫story，最近認為寫story也是一門學問，不過這就是另一回事了~~ XD

敏捷開發(一) 開始研讀敏捷開發書籍的原因

趁我還有印象的時候，寫下之前不好的開發經驗

1.RD 包攬 PM QT的事情

是的，RD需要常常跟其他部門溝通，提供需求給其他部門，跟各窗口討論我們需要的功能，還得去開會了解一些進度的問題，這樣來來回回非常浪費時間。
而QT測回來的東西，RD常常會很難複製，或者QT描述的複製手法很不清楚，必須經過多方溝通，非常浪費時間。

這部分我深深覺得哪裡有問題，但是我也不知道該如何下手。
或許需要將合作的單位都拉在附近一起做事吧，有問題可以直接溝通，直接反應，直接解決，這樣或許就可以省去大量來回的時間。

2.定好的SPEC總是很輕易的翻盤 

UI這禮拜說要這樣畫，然後下禮拜又說要換另一個形式，總是在修改，彷彿RD不需要花時間去架構設計coding一樣，然而project的deadline並沒有因為這些修改而改變，
我其實很好奇這樣的做法是否真的正確，感覺是在哪一環出了問題。

仔細思考之後感覺是上層主管太慢看到成品，通常demo的都是成品，然而這時候才有意見要修改，就必須花很多時間修改，感覺應該要有個代理人，我們可以在每個禮拜或每個月release一個版本給他看，如果代理人有任何的想法應該在那時反應，在這個階段修改，然後之後就不應該再有修改，除非是等到新的版本或者下個schedule才將新的修改加進去。

3.schedule總是定得很短

這使得RD沒有時間可以架構設計，而是直接將手邊有的想法直接倒入程式內，沒有經過多餘的討論，代價就是可怕的架構，難以維護的程式碼。

4.spec更改，RD最後一個知道

某個案子需要跟別的team合作，有些資料必須靠他們的api傳遞給我們，但是...常常spec更新了或修改了我們這邊都沒有人被告知，直到QT測出問題了，我們這邊才知道出事了。
又或者某次UI做了變動，卻沒有同步道所有的人，大家的認知不同，做出來的東西也有誤差。

這部分我深深覺得是彼此溝通的問題，資料沒有同步，我想各單位合作時必須要有個共同溝通平台，或者是能夠同時update彼此最新的進度，並check是否有哪邊是沒有同步到的



run過這樣的案子之後，我對現行run的方式有很大的疑問...
真的是這樣run的嗎???  這句話不斷在我腦海中重複出現

為了能夠解除我內心的疑惑，我花了點時間開始翻閱一些書籍，然後偶然間聽到了敏捷開發，發現裡面的一些想法似乎能解決掉上面大部分的問題，所以，我就這麼踏進了敏捷開發這個世界....也期許在這裡能夠找到我要的答案!!