0%

自动化你的代码

原文链接

你可能也感同身受。在项目刚开始时,每个人都对项目有很多提议——叫做“新项目决议”。经常,这些决议会被写进文档。让代码符合项目的代码标准。在项目启动会议时,开发主管会通过这些文档,在理想情况下,每个人都同意遵循这套规则。一旦项目开始,这些好的建议会被一个又一个地抛弃。到项目收尾时,这些代码将混乱不堪,而且居然没人知道是怎么成这样的。

什么时候开始出错的?可能在项目启动会议就开始了。一些项目成员没有注意到,其他人可能也不理解。但糟糕的是,一些反对声和已经纳入计划的代码标准有冲突。最终,一些人可能发现了问题所在,但项目压力太大的时候,又不得不让事情继续向前推。良好的代码格式化并不能让需要更多功能的用户为你点赞。而且,如果无法自动完成的代码格式化真的很让人反感。仅能自己手动去缩进那些混乱的class。

但如果这是个问题,为什么我们刚开始就要确定一套代码标准?原因之一是格式化成统一风格后没人可以用自己的风格去“占有”一段代码。我们想要阻止开发人员使用明某些反模式,为了避免一些常规性的bug。在所有情况下,一套代码标准应该在整个项目中更容易被执行,以便从头至尾维持开发速度。接着,每个人都应该同意这套风格——如果有人用三个空格缩进,有人却用四个,那这风格就完全没意义了。

有大量的工具可以用来生成代码质量报告以及文档,以维持代码标准,但这不是全部解决方案。它应该尽可能被自动和强制执行。比如以下:

  • 确保代码格式化属于工程建立的一部分,这样每个人在编译自己的代码事会被自动格式化。
  • 使用静态分析工具去扫描代码是否有反模式,一旦发现,中断构建。
  • 学习配置这些工具以便你能扫描自己代码,特定项目的反模式。
  • 不仅要测量测试覆盖率,还要自动检查这些结果。再有,如果测试覆盖率太低也要中断构建。

尝试去把你认为重要的任何事做到这一点。你不能让每件你关心事都自动化。对于这些无法自动标记或修复的事情,考虑为它们制定一套补充指南,以确保代码标准能被自动化,但你和你的同事们未必会遵循它。

最后,代码标准应该是动态的而非静态的,随着项目的发展,它需要随项目改变,因为刚开始看起来英明的事情,过几个月可能就没那么英明了。

小小鼓励,大大心意!