关于提高代码质量的观点

今天在项目讨论中有个话题是如何提升代码质量,简单介绍一下我的观点:

1) 代码风格应该易读易懂,从这个角度来说,过于复杂的LINQ,过长的函数,复杂的判断条件,超长的三元表达式都违背了这个原则,如果代码作者在review时需要很长时间去解释某个函数,应该需要通过注释/需求文档来补充,这段解释应该形成文字。

2)  使用工具而不是靠人品保证某些基本的规则,有没有把project setting的代码分析选项打开?有没有使用最高的标准,类似下面这种简单的警告有没有顺手fix的习惯,加入代码有没有要求人review的习惯,fix defect是否添加了足够的测试用例,有没有试图在本地跑一跑Sonar检查。如果用时间紧项目复杂作为理由,这些的确都算说得过去,但也都可以挤出时间来做,不需要非得什么特定时间。(对于进入产品环境的项目,有另外的要求)

3)  任何时间,代码质量和任务进度都需要权衡,测试时间越多,自动测试用例越多,那当然是越好,但我们作为GDC,其实任务完成量也很重要。我们需要找到一个比较好的平衡点,不在测试上和UnitTest过多投入,也不是过分追求进度忽视质量,这也是我建议大家尽量多写自动UnitTest的原因,随着项目进行,这种投入产出会变得越来越值得,尤其是针对我们这种开发时间比较长的项目,否则我们只能增加手动测试时间,反而得不偿失。

发表评论