浏览 1928 次
锁定老帖子 主题:如何提高代码质量
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-04-02
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%。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-04-03
尽量封装,
|
|
返回顶楼 | |