沒什么技術含量的Remove Before Flight


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

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標識的代碼,所有臨時的日志輸出調用立馬顯形,逐一刪除,確保代碼能夠成功編譯,就可以着手提交了。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM