保持构建的干净

Keep the Build Clean

你有没有看过编译器警告列表,是关于坏代码的语句长度,并想到自己:“你知道的,我却是应该做些什么…但我刚才没时间呀?”另外,你是否留意过刚才出现的一条警告,并修复了它?

当我开启一个新项目时,没有警告、没有杂乱、没有问题。但随着代码库的增长,如果我不注意的话,这些杂乱、冗余(cruft)、警告,及问题就会开始堆积。当大量的噪音出现后,从数以百计的、我并不在意的警告中找出那个我却是需要阅读的警告,就会变得更困难。

为了让警告再次有用,我对这些编译产生的警告采取零容忍。哪怕这些警告根本不重要,我都会处理掉。如果不是关键性的,但仍然相关,我也会修复它。如果编译器提示有个潜在空指针的异常,我就从源头修复——哪怕是我明确知道这个问题根本不会出现在生产环境。如果内嵌文档(Javadoc或者similar)引用已经被删除或者重命名,我就会清理文档。

如果有些事情我确实不关系也确实不用操心,那我就问团队是否可以修改我们的警告策略。例如,我发现一个方法的参数和返回值在多数情况下都不会被添加任何值,那我们删除它就不应该得到警告。或者,编程语言升级到新版本后,之前的已经OK的代码也会发出警告。例如,当Java5引入泛型后,老代码中没有特别申明为泛型的参数都会给出一个警告。这是一种我不想被唠叨的警告(至少,曾经是)。有一套与现实不符的警告并不能服务任何人。

通过确保构建总是干净的,每次遇到警告时,我就不必决策它是否无关紧要。忽略事情是一项脑力劳动,我要摆脱所有不相关的脑力劳动。有一个干净的构建也可以让他人更容易接手我的工作。如果我留下警告,其他人将不得不面对这些相关或不相关的错误。或者干脆忽略掉所有金高,包括那些重要的内容。

构建中的警告很有用。你只是需要在它们刚开始出现时就摆脱它们。不要等到非得大扫除。当那些你不想看到的事物出现时,正确地清理它们。修复警告的源头,要么灭了这些警告,要么修改警告的策略。保持构建的干净不紧紧实保证没有编译错误和测试失败:警告也同样重要,是代码卫生的关键。

0%