航空業有很多值得我們借鑒和學習的工作方式，將來有時間我會給大家引薦更多實例。 仔細觀察每架停泊著的飛機，會發現機身很多地方都掛著細長的紅布條，上面寫著“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標識的代碼，所有臨時的日誌輸出調用立馬顯形，逐一刪除，確保代碼能夠成功編譯，就可以著手提交了。
