专业程序员
本文翻译自"The Professional Programmer",来自于《程序员应该知道的97件事》一书中的某个章节。 什么是专业程序员? 一个专业程序员的唯一的、最重要的特点是个人的责任。专业程序员会对他们的职业生涯负责,会对他们的估计负责,会对他们的计划承诺负责,会对他们的错误负责,会对他们的技艺负责。一个专业程序员绝不会将他们的责任推到其它人身上。 ...
本文翻译自"The Professional Programmer",来自于《程序员应该知道的97件事》一书中的某个章节。 什么是专业程序员? 一个专业程序员的唯一的、最重要的特点是个人的责任。专业程序员会对他们的职业生涯负责,会对他们的估计负责,会对他们的计划承诺负责,会对他们的错误负责,会对他们的技艺负责。一个专业程序员绝不会将他们的责任推到其它人身上。 ...
本文翻译自"Continuous Learning",来自于《97 Things Every Programmer Should Know》一书中的某个章节。 我们生活在一个引人入胜的时代。软件开发分布在全球各地,你知道那里有很多人可以胜任你的工作。你需要不断学习以保持你在市场上的竞争力。否则,你将变成一条恐龙,专心从事某一个工作,直到有一天,你不再被需要或者你的工作被外包给了其它更为廉价的开发人员。 ...
本文翻译自"Code Reviews",来自于《97 Things Every Programmer Should Know》一书中的某个章节。 你应该做代码评审。为什么呢?因为代码评审可以提高代码质量并且降低缺陷比例。但进行代码评审未必是因为你想到的那些理由。 由于之前有过一些代码评审的糟糕体验,因此许多程序员不喜欢代码评审。我曾经见过一些组织,它们要求所有代码在部署到生产环境之前必须通过一个正式的评审。多数情况下由架构师或一名主程序员进行这些评审,这种做法被戏称为“架构师评审一切”。这个要求被写在了他们的软件开发过程手册中,因此程序员必须遵守。可能有一些组织的确需要这样一个严格且正式的过程,不过大多数组织并不需要。在大多数组织中,这样做法只会适得其反。被评审者会感到他们就像是在等待一个假释裁决委员会的判决。而评审者既需要时间阅读源码,还需要时间跟上系统的最新进展,了解系统的全部细节。评审者很快就成为了这个过程的瓶颈。而这个过程也会很快地成为众矢之的并变得愈加糟糕。 ...
记得上次折腾Review Board这个在线代码评审工具还是在一年前,那时的Review Board版本是1.0.3;这周部门的一位同事也在折腾Review Board,不过现在的版本已经升级到了1.5.1了。新版Review Board显然修正了许多旧版本中存在的问题,另外无法支持ssl邮件端口的问题也被我这位同事通过更换django源文件的方式搞定了。Review Board好用了,下一步需要关注的就是怎样才能用好Review Board的问题了。 ...
上周初参加了一次代码评审,评审时发现一位同事在自己负责的子模块代码里定义了一个私用宏,“重复"这个Bad Smell立马在我头脑中闪现。当时我给出了一个建议:检查一下这个宏定义的必要性,依次检查一下C运行库头文件中是否已经有了同功用宏定义,基础库头文件中是否已经有了同功用宏定义,业务层代码的共用头文件中是否已经有了同功用宏定义。 ...
Review Board安装成功至今已半月有余,这期间我一直在试用它,虽欣喜于其提供的强大的功能,但还是有若干使用中的问题一直让我头痛不已,同时也阻碍了在部门推广该工具的进程。 ...
目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式,代码Review多采用走查方式,即代码写完后召开一个Code Review的Meeting,集中时间和经验丰富的人力对重点代码进行筛查,这种方式的代码Review有利,但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时,而在这段时间里不是每个参与者都能极其高效的参与到走查中的,实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小,一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。 ...
一口气读了七章"Code Complete 2nd(以下称CC2e)“中的内容,从第七章的"高质量的子程序"到第十三章的"不常见的数据类型”。之所以一口气读这么多,是因为被其中的内容吸引了。这两天的下午一直在做代码评审,所以晚上看CC2e的时候,思维不停的在项目代码和书中内容之间跳转。一直把"代码大全2nd"当作一门百科全书式的手册类图书,买回来后一直陈放在书架上没有问津。直到今天在考虑一个关于断言使用的问题时,才想起来去查查这本百科全书,想看看书中是如何阐述断言的。于是便拿起了这本书。 ...
记得刚到公司做第一个项目时,mentor要和我一起看看我刚实现完的一些代码,当时有些不解,难道是不相信我写的代码么?最后事实证明:我的代码中有很多缺陷,有的还是很严重的缺陷。后来知道这个过程叫’代码评审’,是保证软件质量的一种手段,而且是很重要的一种手段。代码评审的形式有多种,最正式的一种就是召集公司或者部门的一些’大牛’们,围坐在会议室中,一行一行的审查你的代码;简单的形式就像我和mentor做的那种,一个编写代码的人和一个对系统特别了解的人在一起评审,效果不见得不如正式的评审,起码我是这么认为的。 ...