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