`
JackyCheng2007
  • 浏览: 249656 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

如何提高代码质量

阅读更多
       本文是写给开发人员的建议,不会涉及很多QA方面的讨论。我觉得有三个方法可以提高软件质量,根据重要性和有效性一次为:Code Review, Refactor和Unit Test。这三个方法不是三个阶段,而是同时交叉进行的。
1. Code Review - 逻辑分析
       当需要开发或者新增一些功能的时候,首先就是设计实现方案,然后开始编码实现。我觉得在开始编码之前,需要思考一下你的实现方案的逻辑。这个设计是不是合理的?能不能满足需求,有没有漏洞?在能想到的各种情形下是否能工作?和现有的其他逻辑是否能保持一致性。不要在你还没有像清楚逻辑合理性之前就开始编码。在思考这些问题的时候,你可能需要和用户沟通你的理解,和其他设计人员或者开发者沟通你对别人的相关逻辑的理解,尤其是和你的将要实现的功能有交互的功能逻辑。准确把握好这些问题之后,就可以开始实现了。
        表达逻辑性的一个关键就是确保每一个变量名,方法名和类名都有明确单一的语义。
        当然,一开始不可能完全回答这些问题,只能尽量,至少一些核心关键点要高清楚,不然,你的努力方向有可能是错的。所谓“方向比距离重要”,不要急于开始,一面南辕北辙。在编码和测试中,你还要回头对这些问题思考和论证。对于复杂的逻辑,最好准备一个笔记本,画下你的思考,便于回头分析和查看。
2. Refactor
    重构有太多的好处,我想说的时候它能很好地提高你的代码质量,重构使得代码更为易读,能让你更好的review你的代码和逻辑,从而发现设计上的bug,及时解决。通过code review可以发现和解决很多在测试中无法或者很难发现的bug。反过来,如果代码设计的好,基本上没有什么是在测试的时候发现的bug在code review的时候发现不了的。
3. Unit Test
    我说的Unit test,必须是自动化的测试。刚开始因为懒,或者时间紧,你可能不写测试,这其实就是欠下了债务,越往后,你越觉得没有时间,同时你又不得不靠手工加班去找bug,尽管你花了几个小时才找到的bug,可能一分钟就搞定了,那时就会捶胸顿足。
    在测试的时候,你需要再思考你的逻辑,从API或者用户的角度去思考,同时还要重构你的代码,以易于测试。
    想想看,在你的开发工作中,你的debug时间占据了整个时间的比例大概是多少。我们的开发活动大概是这样的:分析和确定需求,设计实现方案,编码,单元测试,集成测试。大部分programmer都工作在设计实现方案到单元测试之间。分析和确定需求主要由项目经理或者产品经理来做,当然dev也可以给建议。集成测试一般由QA来完成。debug活动存在于单元测试和集成测试过程中。对于单元测试,你采用手工测试,也可能采用自动测试。集成测试也一样。
       在你做单元测试的时候,你会有大量的debug工作。在QA做集成测试的时候,他们会给你提bug,这时候你还要debug。如果再单元测试的时候,你能用10分钟发现bug,2分钟解决bug,那么如果这个bug是QA在集成测试的时候给你提出来的,并且是3天或者一周后才给你提出来的,你大概需要几十分钟debug来确定问题所在,然后还可能是2分钟就解决了。
     
       所以说,bug大部分情况下好解决,但是难找,并且越早去找,越容易找到。这还没有算上因此blockQA的时间,重新部署的时间,还有沟通和重现bug的时间。这大概是为什么大家强调单元测试的重要性。

       但我也不赞成写太多的测试,只写我认为比较复杂,比较重要的测试,我认为只要覆盖30%左右就好了。希望这30%的功能是用户在常用的那70%。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics