航空業(yè)有很多值得我們借鑒和學(xué)習(xí)的工作方式，將來有時(shí)間我會(huì)給大家引薦更多實(shí)例。

仔細(xì)觀察每架停泊著的飛機(jī)，會(huì)發(fā)現(xiàn)機(jī)身很多地方都掛著細(xì)長(zhǎng)的紅布條，上面寫著“REMOVE BEFORE FLIGHT”，中文翻譯成“飛行前拆除”。這種布條沒什么技術(shù)含量，但是非常重要！

比如，為了避免雜物或者昆蟲進(jìn)入皮托管，一般會(huì)給皮托管戴上套子，但是起飛前必須取下套子，否則飛行員就無法獲得空速數(shù)據(jù)，從而導(dǎo)致事故。還有起落架安全插銷，預(yù)防飛機(jī)在地面時(shí)起落架意外收起，但是忘記拔掉的話，起飛后就會(huì)因?yàn)闊o法收起起落架而被迫返航，雖然不至于墜毀，但是燃油損耗（包括可能需要進(jìn)行空中放油）、折舊（比如輪胎、剎車的磨損）等，成本咂舌。

在這些不起眼但又不能跟隨飛機(jī)上天的部件上掛一根紅布條，便是為了機(jī)務(wù)人員做航前檢查時(shí)避免疏漏。

觸類旁通，這根小小的布條，對(duì)于程序員朋友們也很有實(shí)用價(jià)值。掛在沖鋒衣上？掛在雙肩包上？Stop，說正事兒！

我們?cè)谡{(diào)試代碼的時(shí)候，常常會(huì)寫死一些變量的值，比如GPS坐標(biāo)、數(shù)據(jù)庫查詢條件、輪詢時(shí)間間隔、版本號(hào)等等，這些定值方便了調(diào)試工作，但是就像皮托管套和起落架銷子一樣，是絕對(duì)不能隨著軟件更新發(fā)布出去的——嚴(yán)格地講，甚至都禁止合并到主干代碼。

不幸的是，人是不可靠的。很多時(shí)候我們都會(huì)因?yàn)橥藢⑦@些定值移除結(jié)果導(dǎo)致程序無法正常工作。其實(shí)都是些低級(jí)錯(cuò)誤。

分享一下我的做法，沒啥技術(shù)含量，希望能給你帶來些許啟發(fā)。當(dāng)然，也歡迎更好的建議！

假設(shè)有一個(gè)定時(shí)刷新數(shù)據(jù)的功能，實(shí)際業(yè)務(wù)要求每2小時(shí)檢查一次，時(shí)間間隔定義如下：

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

調(diào)試的時(shí)候，為了縮短等待時(shí)間，我們可以設(shè)為5秒一次。

private static final long INTEVAL_DATA_RELOAD = 5_000;

于是這里就存在一個(gè)隱患，2小時(shí)被縮短為5秒鐘，代碼本身沒有問題，所以別人在審核這段代碼的時(shí)候，除非對(duì)業(yè)務(wù)需求很了解，否則不大可能注意到5秒只是調(diào)試代碼，不能提交到服務(wù)器更不能打包發(fā)布。

我的慣用做法就是，同時(shí)保留兩段代碼：

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

我會(huì)告訴我的同事，code review的時(shí)候，任何帶有“Remove before flight!”標(biāo)記的代碼，除非是注釋掉的，否則都不能提交。并且我也鼓勵(lì)他們使用同樣的標(biāo)記來標(biāo)注代碼。

上面代碼有個(gè)好處，使用快捷鍵，刪一行、取消注釋一行，兩步操作迅速恢復(fù)原貌。

所以我在提交代碼前，會(huì)全文搜索“Remove before flight!”，然后逐一刪除或注釋掉。當(dāng)然也可以從TODO框里直接定位，不過如果項(xiàng)目里還有很多其它TODO標(biāo)記，那還是全文搜索比較保險(xiǎn)。

為了方便添加這個(gè)標(biāo)記，我會(huì)使用代碼模板功能，以Android Studio為例，在Live Templates里添加模板：

這樣就只需在要添加這個(gè)標(biāo)記的位置輸入“rbf”，然后一Tab就出來了。

還有一種情況也會(huì)產(chǎn)生大量冗余代碼。當(dāng)我們?cè)谡{(diào)試一個(gè)調(diào)用關(guān)系很深，尤其是存在大量回調(diào)的bug時(shí)，常常不得不靠輸出很多日志來觀察代碼的實(shí)際運(yùn)行情況。一方面，這些Log的輸出可能是實(shí)際開發(fā)不需要的；另一方面，因?yàn)轫?xiàng)目本身也存在很多日志，比較容易混在在一起。如下是我的習(xí)慣：

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));
        }
    });
}

因?yàn)門AG是公開級(jí)別，所以在其它類、包里面，只要是這個(gè)bug牽扯到的地方，都可以使用同一個(gè)TAG，然后在Logcat里設(shè)置filter為“BUG9321”，就可以非常清楚地了解代碼的實(shí)際執(zhí)行情況，提高修復(fù)問題的效率。搞定了bug之后，刪除標(biāo)有RBF標(biāo)識(shí)的代碼，所有臨時(shí)的日志輸出調(diào)用立馬顯形，逐一刪除，確保代碼能夠成功編譯，就可以著手提交了。