2015年9月20日 星期日

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

2015年9月15日 星期二

MarkDown

其實這篇文章是想要稍微推薦一下markdown
markdown其實是個很輕量的語法,由於用google blog的介面寫blog真的很麻煩

  1. 沒有code block
  2. 排版十分不易
  3. 沒辦法即時預覽

這些使用markdown語法 + stackedit 之後所有的問題都迎刃而解啊!!
我想應該會使用這個editor寫一陣子吧!!

順便熟悉一下新editor的用法

Android 開發(一百零四) what's new in andorid studio 1.4 preview

先看一下下面這張圖


這代表什麼?
代表或許在android studio 1.4 正式release 之後,或許就可以支援
使用vector 產生圖檔了!!

有興趣的人可以先去下載新版的android studio 1.4 beta
然後將build.gradle的 gradle版本改成1.4.0-beta1

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.4.0-beta1'
        // NOTE: Do not place your application dependencies here; they belong        // in the individual module build.gradle files    }
}

然後就可以使用這項功能了,記得在import圖檔之後要sync一下,接著檔案就會產生了
這對UI真的是一大福音啊!!,之後只要出一張vector就好了!!

不過這項功能目前還沒發佈,可以再期待一下囉!!

Android 開發(一百零三) dex-method-counts

今天要講的是app 的method counts

為什麼我們要注意method counts?
因為android 有65536的method count的限制

如果app的method數超過了65536就會無法build成功,
所以為了提早發現提早治療,所以我們必須常常觀察method數是否超出預期

從前並沒有方便的工具去觀察method數,不過最近觀察到github上有人提供了簡單的檢驗方式 https://github.com/mihaip/dex-method-counts

小弟依照了上面的方式稍微檢驗了我們家的app

其實已經快爆了XD

不過如果你檢驗了app後發現遇到跟我類似的情形的話,其實不太需要擔心
因為google 已經想到了這個,所以他提出了 https://developer.android.com/tools/building/multidex.html

multidex,只要利用multidex就可以解決掉這個問題

根據google 的文件我們首先必須import multidex的lib

dependencies {
  compile 'com.android.support:multidex:1.0.0'
}
接著必須在build.gradle裡加上multidexEnabled

    defaultConfig {
        
        multiDexEnabled true

    }
我們必須將原本的application改成繼承MultiDexApplication

public class MyApp extends MultiDexApplication  {

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(this);
    }

這樣就完成了

不過注意一下,multidex還是有一些限制的,
例如必須要在版本14以上,還有可能會造成build的速度變慢之類的問題

最後,如果有寫test case 的人,而且有用AndroidJUnitRunner的話
可能會想問要怎麼在multidex版本上面正常測試

方法很簡單,首先必須在test的folder裡自建一個runner
這個runner必須必得要使用multidex.install

public class MyRunner extends AndroidJUnitRunner {

    @Override
    public void onCreate(Bundle arguments) {
        MultiDex.install(getTargetContext());
        super.onCreate(arguments);
    }
}

接著必須在build.gradle裡加上testInstrumentationRunner

    defaultConfig {
        minSdkVersion 14
        targetSdkVersion 22

        testInstrumentationRunner "com.MyRunner"
        multiDexEnabled true

    }

這樣就完成了,就可以使用舊有的annotation了