沒什麼技術含量的Remove Before Flight

麥機長發表於2018-03-04
REM

航空業有很多值得我們借鑑和學習的工作方式，將來有時間我會給大家引薦更多例項。

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裡新增模板：
Remove Before Flight Template

這樣就只需在要新增這個標記的位置輸入“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標識的程式碼，所有臨時的日誌輸出呼叫立馬顯形，逐一刪除，確保程式碼能夠成功編譯，就可以著手提交了。

相關文章