自我总结:
1. 基本上算是有兴趣
2. 基本上算是自学能力还不错
3. 多用订阅(Google阅读器), 多看电子书英文书
4. 个人目标还算比较明确
5. 多熟悉各种开发辅助工具,熟悉测试
6. 学习自动化工具,Python。
版权声明
本本系列文章,作者皆保留版权。转载必须包含本声明,保持本文完整,原作者 编程随想. 本文原始地址:
http://program-think.blogspot.com/2009/01/0.html
如何成为优秀开发人员[0]:怎样算是优秀的?
有感于国内软件开发人员的素质普遍低下,招聘程序员往往面试了N个人都看不到一个顺眼的(当然这里面有很大原因是教育体制的问题)。因此考虑写一个系列,聊一下“如何成为优秀的开发人员”这个话题。
要想成为一个优秀的开发人员,先得搞清楚什么样的开发人员才能称得上是优秀的?要给“优秀开发人员”下一个准确的定义有一点点困难,于是我用举例来说明。
经我多年观察,对于大部分的软件开发团队都有这样的一个现象,那就是团队中的少数(一 般来说,小于总人数的20%)开发人员具有更快的开发效率、更好的程序设计、更好的代码质量、更善于debug、更能够解决技术难题......(总之就 是让TeamLeader事事省心)。而且这一小撮开发人员的贡献总和可能与另外那一大撮人(大于总人数的80%)的贡献总和不相上下(甚至可能超过)。 那么,这一小撮开发人员,就是我所谓的优秀开发人员。(跑题一下,实际上这就是二八原理的一种生动体现,请看二八原理系列的帖子)
说到这里,列位看官应该明白我所指的“优秀开发人员”是什么样的了吧?(如果个别读者还是不明白,那只能说明你智商偏低,本系列帖子不适合你)
如果你觉得自己目前还不属于这一小撮之列,但是希望自己日后成为他们中的一员,你该怎么做呢?我的建议就是:仔细阅读后续的“如何成为优秀的开发人员”系列文章。我会在里面逐一介绍相关的东东,或许有助于你能力的成长。
反之,如果你自认为已经完全符合我所说的优秀开发人员,那么恭喜你,你可以直接略过该系列文章,去看点别的什么东西吧 :-)
本系列不会涉及到具体的编程语言技巧、不会涉及到具体的开发工具、不会涉及到具体的软件框架、不会涉及到任何当下时髦的概念(比如什么OOP、FP、Pattern、SOA、REST、RIA......)。至于我具体会聊些啥,大伙看了以后就知道了。
最后补充声明一下:这里所说的优秀开发人员和开发大牛(西洋文叫做Guru)不是一回事,看完这个系列文章或许有助于你成为优秀开发人员,但并不能帮助你成为开发大牛。
为了方便阅读,把本系列帖子的目录整理如下:
1、关于兴趣
2、关于自学能力
3、设定个人发展目标
4、做正确的事
5、正确地做事(概述)
6、正确地做事(善用工具)
7、正确地做事(善用自动化)
8、......
http://program-think.blogspot.com/2009/01/0.html
如何成为优秀开发人员[1]:关于兴趣
上一篇帖子 已经给出了"优秀开发人员"的定义,那么现在我来说说成为优秀开发人员的头一个重要因素:兴趣 。
因为物理学超级大牛老爱曾经说过:兴趣是最好的老师。我对此深以为然。所以我们先从兴趣这个话题聊起。
兴趣这玩意是心理学层面的东西,据说人在本能上有一种"构建"的快感(例如小朋友喜欢搭积木就是)。有些人天生喜欢写程序,就是因为能够从中体会到构建的快感。鉴于心理学不是本博客重点关注的话题,暂不再深入聊下去。
有兴趣的开发人员和没兴趣的开发人员,差别怎么就这么大捏?这主要是因为有兴趣的人,比较有动力去学习新东西、碰到新鲜玩意喜欢去刨根问底、碰到有开发过程的困难(比如一些难调试的bug)也显得比较有耐心、......久而久之,两种人的差别就渐渐地体现出来鸟。
所以,如果你属于下列情况之一:
1、即将进入学校学习软件这门专业
2、已经从学校毕业,即将入这个行当的新手菜鸟
3、已经工作了若干年,但还不属于优秀开发人员
4、已经在其它行当工作了若干年,觉得软件这行不错,想转行过来
并且企图在将来成为一个如我所说的优秀开发人员,那么你首先要判断一下,自己是否确实喜欢 软件开发。用如下简单的问题就能够判断出你是否确实喜欢 软件开发:
假设有两个工作岗位A和B供你选择。
工作岗位A:你可以随意地去干除了软件开发之外 的任何事情(只要你喜欢的,都可以);
工作岗位B:你必须全职从事软件开发,不能干其它事情。
并且岗位A的收入比岗位B高很多。
对上面这个问题,你会选择哪个工作岗位?如果你毫不犹豫(其实稍微犹豫一下也没太大关系)地选择B,那么恭喜你,你确实 对软件开发非常 热衷。我建议你把"如何成为优秀的开发人员"这个系列的帖子都看完,对你会有帮助。
看到这里,可能有读者要问了:如果我原先对软件开发兴趣不大,有什么方法能让我变得对软件开发非常热衷?
想回答这个问题,大伙先要明白这样一个事情:根据心理学(不好意思,又扯上心理学了)的研究,大部分人的性格、兴趣、气质等因素,大都形成于20岁左右 之前。在20岁左右之后 ,一般不会有太大的改变。
所以,你如果已经从学校毕业,又工作了若干年,那么你的兴趣多半已经定型,改变的机会和效果不大(但也不是绝对不可能改变)。兴趣这种东西是自然形成的。依靠主观愿望去改变自己或者别人的兴趣,最终的效果并不理想。与其这样,不如找一个自己真正感兴趣的行业去做。
反之,如果你年龄尚小(不到20岁),还在读中学(甚至小学),那你现在还不必考虑"如何成为优秀开发人员"这个问题。在这个年龄段,重要的是发现自己的兴趣点在哪里,并让它充分发挥出来。
关于兴趣的话题就聊到这里,下一个话题咱们来聊聊“自学能力 ”。
http://program-think.blogspot.com/2009/01/1.html
如何成为优秀开发人员[2]:关于自学能力
通过本系列上一篇帖子,你应该已经搞清楚自己是否确实有兴趣从事软件开发工作。现在我们来聊一下开发人员的自学能力(终于开始介绍实质性的东东了)。
★自学的重要性
为啥我把“自学能力”排到“兴趣”之后捏?因为大伙儿都明白,IT这行知识的更新速度巨快。有很多新玩意儿在你读书的时候还没有发明出来呢?退一步讲,即使某个新技术在你上学的时候已经发明出来,你的计算机老师也未必会教你(或许他/她自己也不懂)。再退一步讲,即使你上学时的计算机老师比较牛,会把当时新出来的某个技术教给你,但是你将来工作中需要用到的新技术未必就当年老师教给你那个......
上面啰嗦了一大堆,无非想说,你工作中终归会需要用到某个新技术是你以前没学过的。所以,自学能力是非常重要滴。以此相对照的是:国内的大多数开发人员都比较缺乏自学能力(这个也跟国内的教育体制有关)。所以,对于立志成为优秀开发人员你,需要先搞定自学能力这个东东。
★自学的主动性
我把国内的开发人员按照自学的主动性不同,分为如下几类(你顺便想想自己属于哪一类):
1、抗拒自学者
这类人不愿意自学(部分人是由于懒惰、另一些是由于抵触新事物)。当工作中要用到某项新技术而需要自学时,他/她就找若干理由推诿。我估计这类人占的比例不多,万一你正好属于这种人,那还是趁早改行,别在这个行业浪费青春了(因此也别再继续看这个帖子了)。
2、被动自学者
这类人平时没事不会想到去自学新东西。只有当上司逼着他去学XX技术,他才勉为其难地去学。我建议这类人也不用继续看这个系列的帖子了,找个凉快的地方呆着去吧。
3、需求驱动型自学者
这类人自学的动机和方向是基于需求驱动。比如因为工作中要用到XX框架、XX库、XX软件,然后就利用业余时间找资料去看。如果你属于这类人,就得考虑考虑向第4类人转型。
4、计划型自学者
这类人自学的动机和方向是基于自己的规划。定期看看自己的知识结构有什么缺陷、将来自己想朝什么方向发展、最近哪个新东西将来会用得上、......然后给自己定一个学习计划。如果你属于这类人,恭喜你。
★自学的常用招数
现在,咱们来聊聊和自学有关的几个常用招数。
1、搜索引擎
由于使用搜索引擎是互联网时代的必备基本功,搜索引擎的重要性我就不多废话了(千万别跟我说你还不懂得用搜索引擎啊)。
2、百科类网站(例如中文维基百科、百度百科)
百科类网站,顾名思义,就是拿来当百科全书使的。当你听说某个时髦的新术语,但又不甚了解,这时候就可以用上百科类网站了。各种专业术语一般都可以在百科类网站上查到比较具体的解释。不过百科类网站的功能也就仅限于此,当你需要深入了解某个技术时,它是远远不够的。
3、订阅“BBS、Mailing List、Blog”
这3种东东的特点是具有一定的交互性,而且大都支持软件订阅。通过订阅一些专业的、针对某个领域的“BBS、Mailing List、Blog”,你可以了解该领域的实时动态、了解该领域的热点话题、了解该领域的发展方向。你自己如果碰到疑难杂症,还可以在上面找人问(运气好的话还能交几个朋友)。
为啥我特地强调“订阅”捏?因为使用订阅可以让信息自动跑到你面前,省去了打开浏览器挨个访问网站的麻烦(因此也节省了时间)。这3种东东的局限性是:难以通过它们系统性地掌握某个比较复杂的技术(比如你要学习某个有一定复杂度的编程语言)。
4、看书(包括电子书和纸版书)
当你要系统性地掌握某个比较复杂的技术时,首选方法是:找一本针对性的好书。由于每一个具体的领域,都有N本书可供选择,这时候如何取舍就非常重要。如果你选的书比较差,不但看起来吃力,甚至会把你带到沟里。这时候你就得利用搜索引擎或者专门的网站(例如豆瓣、亚马逊)来识别好书与坏书。关于如何鉴别一本书的好坏,我在帖子“如何选择IT技术书籍”里有深入讨论,这里就不再啰嗦了。
再来说说电子书和纸版书。首先电子书的资源非常多,大部分国外出版的IT书都可以在Internet上找到免费的电子版。另外还有电子书还有如下好处:便于携带、能全文搜索、能共享、能备份、还省钱。从目前的发展趋势看,电子书占据主流地位只是一个时间问题。基于上述理由,所以我很喜欢看电子书(可惜大多数人都没有看电子书的习惯)。你如果还没有形成看电子书习惯的话,要开始培养了。
说完电子版和纸版,再来聊聊中文版和英文版。英文版相对中文版的优势就如同电子版相对纸版的优势一样明显。国内懂开发又文笔好的IT作家寥寥无几,导致国内出版的IT技术书籍要么翻译国外(翻译过程一般会导致 1-2年的滞后、翻译质量还未必好),要么粗制滥造。所以,你如果不能流利地阅读英文书,赶紧恶补英语吧!
上述4个招数,如能熟练运用,从此自学无忧矣!
下一个话题,准备聊一下“设定个人发展目标和计划”。
http://program-think.blogspot.com/2009/01/2.html
如何成为优秀开发人员[3]:设定个人发展目标和计划
大部分人从来没有明确地设定自己的发展目标,每天都是得过且过。等到几年过去了,才发现自己这些年啥也没学会,还是老样子,然后就感叹时光飞逝、岁月如梭。因此,今天我们来聊一下如何设定个人发展目标。(如果你平时已经很善于定期设定个人发展目标并执行得很好,恭喜你,那么本帖子你可以略过)
先说说什么是“个人发展目标”。顾名思义,就是和你个人的职业发展有关的目标,包括知识、技能、工作岗位等都可以被设定为个人发展目标。(由于本博客主要关注IT方面,因此我会以个人的技术发展为例来说明,但是这些方法也适用于其他方面,例如个人财务目标)
我一般会把个人发展目标分为“长、中、短”三种类型,以此来对应不同的时间阶段。不管是哪种类型的目标,都要把目标设置得难易适中。太容易的目标对自己的成长帮助不够大;而太难的目标则容易中途放弃或者超出时间(导致打乱计划)。还有,设定的目标要尽量容易评估(否则到时候连自己也搞不清楚到底目标算不算已达到)。
先说说短期目标。短期目标的时间跨度大约在几个星期到一个季度之间。短期目标要定得比较具体,便于自己评估目标是否达成。下面举几个短期目标的例子:“ 在本月读完《Thinking in C++》”、“在本月熟悉Spring框架”、“在这2个月用Flex写一个五子棋游戏”......
然后说说中期目标。中期目标的时间跨度大约在几个季度到1-2年。中期目标比短期目标更抽象,且必须是短期目标的有机结合。比如有个短期目标是“本周看完《Dive into Python》”,那么对应的中期目标可以是“1年内成为熟练的Python程序员”。
最后谈谈长期目标。长期目标同样也必须和中级目标沾边,它的层次当然更高,时间跨度大约在5年以上。而且长期目标一般不会关系到具体的XX语言、XX平台等,倒是经常和职业岗位有一定的关联。比如“5-7年内成为技术总监”、“5年内成为公司产品的架构师”等。
当你把3种目标都设定好之后,就形成了个人发展计划。既然是计划,你就得在每一个阶段结束时自己总结一下,评估一下该目标的完成情况好不好,有什么收 获、有什么经验教训。必要的话还需对尚未开始的后续目标进行一下调整。定期回顾还有一个好处,就是能获得一种满足感,从而有利于你坚持完整个计划。
关于“设定个人发展目标和计划”,今天就聊这么多。不管你是尚未毕业的在校生,还是已经工作多年的老员工(亡羊补牢还不晚),从现在开始,按照我上面说的,赶紧计划一下吧!
下一个话题,打算聊一下“做正确的事”。
http://program-think.blogspot.com/2009/01/3.html
如何成为优秀开发人员[4]:做正确的事
一般来说,优秀的开发人员往往具有较高的效率。我这里提到的效率包括两方面:“做正确的事”和“正确地做事”。并且“做正确的事”比“正确地做事”更加重要。
我们先来看一些反面教材。据相关研究机构统计,大部分人(80%以上)具有如下不好的工作习惯:
1. 先做自己喜欢的事情,再做自己不喜欢的事情
2. 先做紧急的事情,再做不紧急的事情
3. 先做容易做的事情,再做不容易做的事情
4. 先做自己了解、熟悉的事情,再做自己不了解、不熟悉的事情
5. 先做有趣的事情,再做枯燥的事情
6. 先做易于告一段落的事情,再做不易于告一段落的事情
7. 先做自己熟悉的人托付的事情,再做自己不熟悉的人托付的事情
你仔细回想一下,自己是否有上述的坏毛病?(我相信大多数人都有)如果你有其中的几项的话,你平时会很容易被琐事纠缠,白白浪费不少时间,每天忙完了都不清楚忙些啥。那怎么改变这种局面捏?听我细细道来。
“做正确的事”的关键在于评估你准备做的每件事情的权重。权重来源于这件事情对于达成你的目标(我们在本系列上一篇帖子“设定个人发展目标和计划”已经谈到如何设定自己的目标)是否有帮助,帮助有多大。帮助越大,则权重越大。然后,每天醒来,你都要把当天准备做的事情根据权重排好优先级,然后严格按照优先级顺序执行。
如果工作中偶尔碰上看起来紧急的突发事情,也不要轻易改变原先安排的计划表,而要先冷静评估一下这个紧急的事情的权重。只有是紧急且权重高(重要)的突发事件,你才可以调整计划,把这件突发事情加入其中。关于重要性和紧急性的平衡与处理,在杜拉克的名著“卓有成效的管理者”中有详细的介绍,大伙儿如果有兴趣可以去看看。
上面说的这些,看起来简单,但是真的操作起来挺难的。能否修炼成功得看各自的造化了。一般来说,理性的人比感性的人胜算大。如果你是一个感性的人,那更得多努力了。
聊完了“做正确的事”,下一个话题说一说“正确地做事”。
http://program-think.blogspot.com/2009/01/4.html
如何成为优秀开发人员[5]:正确地做事(概述)
从上一个帖子“做正确的事”写完到现在已经过去2周了,有网友已经等不及,在评论中催我了。在此向等待本系列的网友致歉。
和“做正确的事”相对应,“正确地做事”主要讨论的是有关工作效率和工作质量的问题(也就是如何多、快、好、省地完成工作)。由于"正确地做事"这个话题比较大,涉及到几个不同方面的方法论问题,考虑了很久,感觉一个帖子难以全部写完(我不喜欢写长篇大论的帖子)。最后决定搞个子系列,针对每个方面写一个帖子。
如果你是一个在校的学生或者刚入行的新手,这个子系列应该对你很有帮助;如果你是一个团队的小头目(Team Leader),你可以根据这个子系列来培训你手下的新员工。
为了便于阅读,把和"正确地做事"有关的帖子目录列在下面:
1、善用工具
2、善用自动化
3、......
http://program-think.blogspot.com/2009/02/5.html
如何成为优秀开发人员[6]:正确地做事(善用工具)
俗话说“工欲善其事,必先利其器”,今天我们来说说和开发工具有关的话题。由于开发过程中会用到的工具多种多样,根据“二八原理”,我只挑选和开发最密切相关的少数几种工具来聊一聊。
★编辑器
编辑器显然是用的最频繁的工具了(尤其是对于经常写代码的人),但是很大一部分人不善于使用编辑器。因此我先来说一下对编辑器使用的一些体会。顺便提一下,如果你连盲打都没过关,请先去学打字,再回来看这个帖子。
1、字体的配置
对于写代码而言,字体的选择是非常重要的(看起来舒服的字体起码能保护眼睛)。首先必须选择一种等宽的字体(比如FixedSys、Courier New);其次该字体必须能够清楚地区分如下几种容易混淆的字符,避免阅读代码的时候看错:
数字0 和 字母O
数字1 和 大写字母I 和 小写字母l 和 或运算符|
数字2 和 字母z
数字9 和 小写字母q
乘号* 和 字母X
分号; 和 冒号:
2、颜色的设置
你使用的编辑器必须支持自定义的词法高亮(词法着色)。对词法高亮进行设置时,至少要把:“代码注释、关键字、字符串、数字”这几种语法要素用不同的颜色区分开。当然,如果还能根据“类名、函数名、变量名等”进行着色,那就更好了。
3、快捷键
熟练地使用快捷键能大大提高编辑的效率。因为你的手不需要离开键盘去操纵鼠标。而且当编辑的文本比较大时,有些编辑命令即使用鼠标操作也挺费劲(比如全选、移动到文件尾),不如快捷键方便。
所以,你使用的编辑器必须支持快捷键(这个大多数都能做到),而且还必须支持编辑命令和快捷键的绑定(也就是自己设置某个编辑命令对应的快捷键),便于根据个人喜好设置快捷键。
4、其它功能
还有一些比较琐碎的功能,比如:代码自动缩进、自动补全、动态提示等等。最后,如果你需要经常在不同的操作系统上进行工作,那你的编辑器还必须得支持跨平台才行。
虽然说了这么多条条框框,但是符合全部要求的软件并不难找,比如Emacs、VIM、Eclipse等软件都可以满足上述的编辑功能,具体选哪个就看各自的偏爱了。
★源代码管理工具(版本管理软件)
为了打字方便,以下简称RCS(Revision Control System)。
通过RCS的使用状况,可以看出一个开发团队在软件工程方面的成熟度,因此我们接下来要说说RCS的问题。如果你所在的开发团队从来不使用RCS进行代码的版本控制,那我建议你赶紧考虑跳槽。
我观察下来,发觉RCS主要有如下几种误用的情况:
1、不正确的提交频度
有很多新手不习惯使用RCS,很少进行代码的提交。有些人甚至到项目快结束时还没有提交过一行代码。结果导致整个RCS形同虚设。
还有一些人则走向另一个极端,频繁提交代码。有些人每改完一个文件就提交一次,还有些人甚至把修改一半,尚不能编译通过的代码也提交到RCS。
我个人认为,正确的提交频度应该分两种情况:在编写功能代码时,每完成一个功能点,并且自己经过了自测之后,提交一次;在调试的时候,每修复一个bug,提交一次。这样能够保证提交到RCS的代码都是能编译通过的(详见每日构建系列),并且业务逻辑上也是相对完整的(对于每日构建后的测试很重要)。
2、提交时不写注释
很多人提交代码时不写注释,将来再想到版本历史里面找代码就犹如大海捞针般困难。比如在我经手的代码中,有些源代码文件历时3年,提交次数上百次,如果提交时不写注释,日后根本没法找。
3、不做代码基线(Baseline)、不做代码分支(Branch)
在正规的开发团队,每当有一个版本发布(Release)并交付给用户使用时,都需要在RCS中制作一个基线,以便于进行相应的bug跟踪和补丁制作。因此,诸如做基线之类的事情,属于整个团队的集体行为,需要由Team Leader牵头来搞。
假如一个开发团队从来不做代码基线或者代码分支,仅仅是把RCS当成一个源文件的备份工具来用,那至少说明这个团队的Team Leader在软件工程管理方面非常失败。
★用于调试/测试的运行辅助工具
运行辅助工具对于开发效率的影响也很大。一般来说,你自己的开发机器上要有尽可能仿真(和用户的环境相似)的运行环境,并且运行辅助工具能够有效地发现运行时的一些不正常的信息。这样有利于让bug在交付给用户之前尽早暴露出来。
如果你是Web开发人员,那么你自己肯定要安装好常用的浏览器(至少包括IE和Firefox)。对于IE,还得设置成显示脚本错误通知。
如果你主要开发Windows应用程序,你手头肯定要备好诸如:Depends(Visual C++自带)、Process Explorer等工具,便于查看进程、线程、动态库、堆内存等运行时信息。
如果你是搞手机应用的,那么你至少得有目标系统的模拟器软件(如果能配一个真机当然更好)。
如果你主要进行跨平台方面的开发,那么诸如VMware之类的虚拟机软件是必不可少的。
......
限于篇幅,今天就只说这些。其它我未提及的工具,大伙儿自己可以举一反三。下一个话题,打算说说“善用自动化”。
http://program-think.blogspot.com/2009/02/6.html
如何成为优秀开发人员[7]:正确地做事(善用自动化)
上一个帖子 聊了“善用工具”的话题,讲的都是如何有效利用工具来提高效率,今天说一下如何利用“自动化”来提高效率。
隐约记得Perl语言的创始人Larry Wall曾经评价过程序员的三大美德,分别是:懒惰、急躁、傲慢。(刚才找到原文在这里 )在这三大美德中,“懒惰”赫然排在第一,可见其重要(另外,马云似乎也说过类似的名言)。我对他说的“懒惰”的理解,就是干尽量少的活,但是依然保质保量地完成工作。那么,如何才能偷懒捏?一个有效的办法就是:自动化。
我这里说的“自动化”,当然不是大学里自动化专业的那个“自动化”,而是指:利用各种方式(主要是计算机)来帮你自动完成 某些(枯燥、费时、无价值)的重复劳动;然后你就可以利用节省出来的时间,干一些更有意义的事情了(比如学习点有用的东西)。
具体该如何做呢?要实现自动化,首先就要观察你平时做的事情中,有哪些属于重复 劳动;然后评估一下这些重复劳动是否可以用某些工具来替代;如果有可能替代,你就可以动手把这个工具实现出来,然后就让工具帮你做事情了。
说了这么多,感觉有些抽象,下面我举几个方面的例子来给大伙儿加深一下印象。
★Blog订阅
如果你经常看我的Blog,但是没有使用Feed订阅工具,那你就要当心了。你属于不善于利用自动化的人。假如使用了Feed订阅工具,你就不需要经常访问某个URL的页面去看有没有新帖子。因为这个枯燥的重复劳动已经由订阅工具帮你自动完成了。你所要做的,仅仅是在订阅工具中初始化某个URL(只要做一次),然后工具会在有新帖子的时候通知你。所以,除非你要发评论,否则不需要访问我Blog的页面 :-)
★调试程序
估计看我Blog的人,大部分都有过调试程序的经验。当程序行为不正常时,经常需要设置断点,然后单步跟踪代码,以便找出程序出错的源头。其实这个过程也有大量的重复劳动。
我一般喜欢通过程序断言(以下简称assert)来简化上述过程。看到这里,有些同学心里犯嘀咕了:程序断言和自动化有什么关系啊?其实每一个assert就好比一个自动 的代码检查点,每次 程序运行到assert处的时候,如果你设置的逻辑条件不成立,它会立即终止程序并打印出相关信息(比如调用栈、文件行号等)。
如果你在写代码的时候,经常在一些关键点 设置一些条件恰当 的assert,可以大量节约调试时间。我自己写的程序,在自测的时候,有70%-80%的逻辑错误会被assert暴露出来,所以改起来非常快;测试人员提交给我的Bug,大概也有一半以上可以通过assert快速定位出错误的源头。
★自动化测试
说完了程序员的例子,我再说一下测试人员(其实我在“每日构建:流程 ”已经稍微提到了测试的自动化)。我发现很多公司的测试人员,重复劳动特别严重。他们不断地重复做一些软件功能的验证操作;发现bug后通知程序员改;程序员改完,再次进行验证操作......如此循环往复。N年之后,这些测试人员的个人能力没啥提高,年龄倒大了不少。
在此我强烈建议测试人员,尽量多使用一些自动化测试工具(比如QTP )和一些测试脚本来完成上述的软件功能验证操作。不光能节约很多时间,提高了效率;而且在自己编写测试脚本的过程中,或许还能学些新东西,提高一下个人能力。比如我见过一个测试人员,由于经常用Python 写一些脚本进行网络和数据库方面的测试,久而久之,Python就很熟悉,然后就被转做Python编程。
★人肉自动化
上面说的自动化都是技术层面的(都是靠软件实现)。为了给大伙儿扩展一下思路(免得思维定势),最后来说一下非技术的例子。
比如部门中经常有人出差,每次出差都要都要订机票。订机票就属于重复劳动,而且挺繁琐。得去网上查航班、还得看哪个航班折扣优惠、选好航班还得付钱,然后去机场还得打印行程单,出差回来还得填写报销单(报销单还得找N个人签字),然后拿着报销单与行程单找秘书报销。这些琐事累加起来,少说也得一个小时才能搞好。
为了提高效率,上述这些琐事统统都交由秘书搞定。出差的家伙需要做的就是发一个邮件告诉秘书,要订某天某时的飞机到某地,就一切OK了。经过这样改革,部门里的人(除了秘书)皆大欢喜。