沒什麼技術含量的Remove Before Flight

航空業有不少值得咱們借鑑和學習的工做方式，未來有時間我會給你們引薦更多實例。

仔細觀察每架停泊着的飛機，會發現機身不少地方都掛着細長的紅布條，上面寫着「REMOVE BEFORE FLIGHT」，中文翻譯成「飛行前拆除」。這種布條沒什麼技術含量，可是很是重要！

好比，爲了不雜物或者昆蟲進入皮托管，通常會給皮托管戴上套子，可是起飛前必須取下套子，不然飛行員就沒法得到空速數據，從而致使事故。還有起落架安全插銷，預防飛機在地面時起落架意外收起，可是忘記拔掉的話，起飛後就會由於沒法收起起落架而被迫返航，雖然不至於墜毀，可是燃油損耗（包括可能須要進行空中放油）、折舊（好比輪胎、剎車的磨損）等，成本咂舌。

在這些不起眼但又不能跟隨飛機上天的部件上掛一根紅布條，即是爲了機務人員作航前檢查時避免疏漏。

舉一反三，這根小小的布條，對於程序員朋友們也頗有實用價值。掛在衝鋒衣上？掛在雙肩包上？Stop，說正事兒！

咱們在調試代碼的時候，經常會寫死一些變量的值，好比GPS座標、數據庫查詢條件、輪詢時間間隔、版本號等等，這些定值方便了調試工做，可是就像皮托管套和起落架銷子同樣，是絕對不能隨着軟件更新發布出去的——嚴格地講，甚至都禁止合併到主幹代碼。

不幸的是，人是不可靠的。不少時候咱們都會由於忘了將這些定值移除結果致使程序沒法正常工做。其實都是些低級錯誤。

分享一下個人作法，沒啥技術含量，但願能給你帶來些許啓發。固然，也歡迎更好的建議！

假設有一個定時刷新數據的功能，實際業務要求每2小時檢查一次，時間間隔定義以下：

private static final long INTEVAL_DATA_RELOAD = 2 * 3600 * 1000;

調試的時候，爲了縮短等待時間，咱們能夠設爲5秒一次。

private static final long INTEVAL_DATA_RELOAD = 5_000;

因而這裏就存在一個隱患，2小時被縮短爲5秒鐘，代碼自己沒有問題，因此別人在審覈這段代碼的時候，除非對業務需求很瞭解，不然不大可能注意到5秒只是調試代碼，不能提交到服務器更不能打包發佈。

個人慣用作法就是，同時保留兩段代碼：

private static final long INTEVAL_DATA_RELOAD = 5_000;  // TODO: Remove before flight!
// private static final long INTEVAL_DATA_RELOAD = 2 * 3600 * 1000;

我會告訴個人同事，code review的時候，任何帶有「Remove before flight!」標記的代碼，除非是註釋掉的，不然都不能提交。而且我也鼓勵他們使用一樣的標記來標註代碼。

上面代碼有個好處，使用快捷鍵，刪一行、取消註釋一行，兩步操做迅速恢復原貌。

因此我在提交代碼前，會全文搜索「Remove before flight!」，而後逐一刪除或註釋掉。固然也能夠從TODO框裏直接定位，不過若是項目裏還有不少其它TODO標記，那仍是全文搜索比較保險。

爲了方便添加這個標記，我會使用代碼模板功能，以Android Studio爲例，在Live Templates裏添加模板：

這樣就只需在要添加這個標記的位置輸入「rbf」，而後一Tab就出來了。

還有一種狀況也會產生大量冗餘代碼。當咱們在調試一個調用關係很深，尤爲是存在大量回調的bug時，經常不得不靠輸出不少日誌來觀察代碼的實際運行狀況。一方面，這些Log的輸出多是實際開發不須要的；另外一方面，由於項目自己也存在不少日誌，比較容易混在在一塊兒。以下是個人習慣：

public static final String TAG_BUG_9321 = "BUG9321";   // TODO: Remove before flight!

private void validate(String content) {
    Log.d(TAG_BUG_9321, String.format("Validate content: %s", content));

    doValidate(content, new ValidateCallback() {
        @Override
        public void onValidated(String result) {
            Log.d(TAG_BUG_9321, String.format("Validated result: %s", result));
        }
    });
}

由於TAG是公開級別，因此在其它類、包裏面，只要是這個bug牽扯到的地方，均可以使用同一個TAG，而後在Logcat裏設置filter爲「BUG9321」，就能夠很是清楚地瞭解代碼的實際執行狀況，提升修復問題的效率。搞定了bug以後，刪除標有RBF標識的代碼，全部臨時的日誌輸出調用立馬顯形，逐一刪除，確保代碼可以成功編譯，就能夠着手提交了。