自动化你的编码标准
你可能已经这样做了。在一个项目开始时,每个人都有很多好的意向——称之为“新项目决心”。经常是,这些决心很多已经书面记录下来了,和编码相关的最终就是项目的编码标准。在项目启动会议上,主开发过一遍这个文档,而且最好的情形是,每个人都同意会遵守它们。然而一旦项目开始后,这些好的意向就一个一个被抛弃了。等项目交付时,代码已经看起来是一团糟,而且似乎没有人知道它是怎么变成这个样子的。
是什么时候出了问题呢?可能在项目启动会上就有了。某些项目成员没注意,其他一些没有理解。更坏的可能是,有些人根本就不同意而且已经在计划对编码标准的反叛了。最终,有些人理解了也同同意了,但项目的压力变得太大了时,他们只好放任自流了。格式良好的代码相对于一个需要更多功能的客户,不会让你投入更多。此外,如果不自动化的话,遵循编码规范可能是一项很枯燥的任务,只要自己尝试一下手动地调整一个混乱的类的缩进就会明白。
既然有这个问题,但是为什么我们还是在一开始要有一个编码标准呢?一个原因是用统一的方法格式化代码,就没有人可以通过用个人的方法格式化来“独占”一块代码。我们可能要防止开发人员使用某些“反模式”,以避免一些常见的缺陷。总的来讲,一个编码标准应该很容易在项目中使用,也可以自始至终保证开发速度。因此,每个人都应该同意遵守编码标准——如果一个开发人员用三个空格缩进而另一个用四个,这是不行的。
有很多用来生成代码质量报告以及记录和维护编码标准的工具,但那不是完整的解决方案。如果可能的话,应该自动化和强制花。以下是一些例子:
· 确保格式化代码是构建过程的一部分,这样每个人在每次编译代码时都可以自动运行。
· 使用静态分析工具扫描代码,找出其中的反模式;如果有的话,中断构建。
· 学习配置这些工具,这样可以为自己扫描特定项目相关的反模式。
· 不要只度量覆盖测试率,还要自动检查结果;同样,如果覆盖率太低就中断构建。
对你认为重要的每一件事都这么做。不是所有你在意的事情都可以自动化,对于不能自动标记或修复的,将其作为以自动化了的编码标准的辅助性指导,但你或者你同事没严格遵守也是可以接受的。
最后,编码标准应该是变化的,而不是静止的。随着项目的进展,项目需求会变化,一开始很精巧的东西,几个月之后可能就不是那么必需的了。