系统程序员成长计划-写得又快又好的秘诀(三)

发布时间:2009-10-13 08:59    发布者:linux_Ultra
关键词: 成长 , 程序员 , 秘诀 , 系统
系统程序员成长计划-写得又快又好的秘诀(三)
                                                                Thursday, December 04th, 2008 | Author: admin                                                               

转载时请注明出处和作者联系方式
文章出处:http://www.limodev.cn/blog
作者联系方式:李先静
                        代码阅读法
软件工程实践已经证明Code Review是提高代码质量最有效的手段之一,极限编程(XP)更是把CodeReview推向极致,形成著名的结对编程工作方式,两个程序员在一台电脑前面工作,一个人编写程序,另一个Review输入每一行代码,写程序人的专注于目前细节上的工作,Review的人同时要从高层次考虑如何改进代码质量,两个人的角色会经常互换。
可惜我即没有结对编程的经验,也没有在CMM3(及以上)团队中工作过。不过现在我要介绍比结对编程更敏捷更轻量级,但是同样有效的Review方法。这种方法不需要其他程序员配合,有你自己就够了。为了把这种方法与传统的Code Review区分开来,我把它称为代码阅读法吧。

很多初学者包括一些有经验的程序员,在敲完代码的最后一个字符后,马上开始编译和运行,迫不急待的想看到自己的工作成果。快速反馈有助于满足自己的成就感,但是同时也会带来一些问题:
让编译器帮你检查语法错误可以省些时间,但程序员往往太专注这些错误了,以为改完这些错误就万事大吉了。其实不然,很多错误编译器是发现不了的,像内存错误和线程死锁等等,这些错误可能逃过简单的测试而遗留在代码中,直到集成测试或者软件发布之后才暴露出来,那时就要花更大代价去修改它们了。
修改完编译错误之后就是运行程序了,运行起来有错误,就轮到调试器上场了。花了不少时间去调试,发现无非是些低级错误,或许你会自责自己粗心大意,但是下次可能还是犯同样的错误。更严重的是这种debug & fix的方法,往往是头痛医头脚痛医脚,导致低质量的软件。
让编译器帮你检查语法错误,让调试器帮你查BUG,这是天经地义的事,但这确实是又慢又烂的方法。就像你要到离家东边1000米的地方开会,结果你往西边走,又是坐车又是搭飞机,花了一周时间,也绕着地球转了一周,终于到了会议室,你还大发感慨说,现代的交通工具真是发达啊。其实你往东走,走路也只要十多分钟就到了。不管你的调试技巧有多高,都不如一次性写好更高效。
我以前也一样,想赶时间结果花了更多时间,在经过很多痛苦的经历之后,我开始学会放松自己,让自己慢下来。写完程序之后,我会花些时间去阅读它,一遍两遍甚至多遍之后,才开始编译它,只要有时间,在通过测试之后,我还会阅读它们,每读一遍都有不同的收获,有时候会发现一些错误,有时候会做些改进,有时候也有新的想法。
下面是我在阅读自己代码时的一些方法:
o检查常见错误。
第一遍阅读时主要关注语法错误、代码排版和命名规则等等问题,只要看不顺眼就修改它们。读完之后,你的代码很少有低级错误,看起来也比较干净清爽。第二遍重点关注常见编程错误,比如内存泄露和可能的越界访问,变量没有初始化,函数忘记返回值等等,在后面的章节中,我会介绍这些常见错误,避免这些错误可以为你省大量的时间。如果有时间,在测试完成之后,还可以考虑是否有更好的实现方法,甚至尝试重新去实现它们。说了读者可能不相信,在学习编程的前几年,我经常重写整个模块,只我觉得能做得更好,能验证我的一些想法,或提高我的编程能力,即使连续几天加班到晚上十一点,我也要重写它们。
o模拟计算机执行。
常见错误是比较死的东西,按照检查列表一条一条的做就行了。有些逻辑通常不是这么直观的,这时可以自己模拟计算机去执行,假想你自己是计算机,读入这些代码时你会怎么处理。这种方法能有效的完善我们的思路,考虑不同的输入数据,各种边界值,这能帮助我们想到一些没有处理的情况,让程序的逻辑更严谨。
o假想讲给朋友听。
据说在CodeReview时发现错误的,往往不是Review的人而是程序员自己。我也有很多这样的经历,在讲给别人听的时候,别人还没有听明白,自己已经发现里面存在的错误了。上大学时,我常常把写的或者学到的东西讲给隔壁寝室的一个同学听,他说他从我这里学到很多知识,其实我从讲的过程中,经常发现一些问题,对提高自己的能力大有帮助。可惜并不是随时都能找到好的听众,幸好我们有另外一个替代办法,记得刚开始写程序时看过一本书(忘记名字了),作者说他在写程序时,常常把思路讲给他的布娃娃听。我没有布娃娃当听众,讲给鼠标听总是有点怪怪的,所以就假想旁边有个朋友,我把自己的思路讲给他听,同时也假想他来质疑我。这种方法很效,能够让自己的思路更清晰,据说一些大师也经常使用这种方法。
这种代码阅读法会花你一些时间,但是可以省下更多调试时间,而且能够提高代码质量,可以说是名符其实的“又快又好的” 秘诀之一。至于读几遍合适,要根据情况而定,个人觉得读两到三遍是最佳的投资。
本文地址:https://www.eechina.com/thread-4663-1-1.html     【打印本页】

本站部分文章为转载或网友发布,目的在于传递和分享信息,并不代表本网赞同其观点和对其真实性负责;文章版权归原作者及原出处所有,如涉及作品内容、版权和其它问题,我们将根据著作权人的要求,第一时间更正或删除。
wangkj 发表于 2009-10-13 09:25:47
理论上如此,但是,很多问题,必须摸索才能发现。
俺现在的显卡代码不超过1000行,调试了几个月,就是有些问题不太清楚,
只能不断的实验和摸索。关键点就是几个数字。
wangkj 发表于 2009-10-13 09:27:11
lz说的这种代码是需求及其明确,软件工具没有bug,对编程环境及其熟悉的情况。
也就是说,软件工人级别的问题。
ebuffalo 发表于 2009-10-13 09:49:10
有几个人不是工人级别?

老王很自信的说.
原野之狼 发表于 2009-10-13 10:00:17
纯软件的可以这样,嵌入式软件一定得调试,因为对硬件的理解有可能出现偏差。
一朝成名 发表于 2009-10-13 22:49:45
多写写,就快了~~~~没办法的办法
xihulu 发表于 2009-10-14 17:13:45
多写,深度钻研基础功能模块的原理,确保每个基础模块的稳定可靠,积累到一定程度就可以不断的复用,包括基础架构等等。尤其是在一个公司,做某个特定行业的开发,通常有很强的继承性,积累3年之后,每个新项目实际需要的工作量其实只是有限的一小部分而已——到时候自然就“又好又快”了。
zengguangjun 发表于 2009-10-26 13:39:00
说的有理,温故而知新嘛!
li_mu 发表于 2009-10-27 11:41:24
回复7楼xihulu

是啊,关键是继承性,每次从头开始就太累了
cxthw 发表于 2011-6-16 16:15:19
“温故知新”,要有足够的耐性去温......
kdsky 发表于 2011-8-25 19:01:06
冰冻三尺非一日之寒,为山九仞非一日之功,路很长啊
octubersun 发表于 2012-2-3 13:24:57
具体环境具体对待吧
您需要登录后才可以发表评论 登录 | 立即注册

厂商推荐

相关视频

关于我们  -  服务条款  -  使用指南  -  站点地图  -  友情链接  -  联系我们
电子工程网 © 版权所有   京ICP备16069177号 | 京公网安备11010502021702
快速回复 返回顶部 返回列表