你如何维持低质量的代码库？

为了能够维护我编写的代码,我必须很好地命名变量,记录我的代码,确保没有重复,抽象正在工作以便不需要黑客..并且谨慎地评论,因为评论经常打扰我阅读码.

但我见过的许多其他代码库更像是一个漩涡.变量名称是foobar,即使从不需要计算东西,也会应用大量的黑客和补丁,抽象失败,部署脚本失败......代码是一种难以理解且几乎无法使用的汤.

所以!我很好奇.你如何设法保持低质量的代码库？

不断重构; 当你打开一个代码文件而你看到一些奇怪的东西时,你可以投入几分钟来改进现有代码的设计.

拥有一套单元测试可以帮助您,因为它可以让您确信您正在更改的代码是否仍然有效或因您的更改而中断.

这有点像在房子里有一个破窗户的故事.当您看到窗户破损时,您应该修理它.如果你不解决它,那么事情将开始在那里发生变化,并且它将导致一个不可维护的混乱.

我的大部分项目也都投入了ContinuousIntegration; 在构建和运行单元测试之后,还执行静态代码分析(fxcop).我不时地看一下结果,并尝试修复一些报告的违规行为.

通常你所描述的是任何代码库增加熵的自然趋势.它通过开发和维护而发生在每个项目中.为了对抗这种稳定增长,我建议如下:

团队中有足够权威的人必须关心.这是最重要的部分.如果没有人关心,它将无法完成.这一点似乎很明显,但事实并非如此.

制定标准和最佳实践.大多数语言都有一本人写的关于最佳实践的书.例如在PERL中,Damain Conway有一本非常好的Perl Best Practices书.除非你这样做,团队中的每个人都有自己的方式来编写代码,命名变量,评论等等.

代码评论.您需要一份代码审查清单.您的更改工作是不够的,它还必须符合最佳实践列表.我们建立了两层代码审核,第一层是同行代码审核,第二层是关注代码质量的发布经理.

设计评论.在错误跟踪系统中填写错误或增强功能时,重要的是由变更控制委员会审核,决定工作的安排以及谁需要审查工作的设计.这是您维护代码抽象的地方,并确保更改符合项目的设计文档和目标.团队的软件架构师或首席设计师应该是CCB的一部分.

签入代码质量触发器.一些最佳实践可以通过代码直接实施.编写小脚本来检查代码,例如格式化,使用制表符/空格等.这将帮助您以不同的方式考虑代码质量.

一些阅读作为参考.

学科