如何成为优秀开发人员 系列文章 - by 编程随想

 

自我总结:

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了。经过这样改革，部门里的人（除了秘书）皆大欢喜。