没什么技术含量的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标识的代码，全部临时的日志输出调用立马显形，逐一删除，确保代码可以成功编译，就能够着手提交了。