如何成为优秀开发人员（系列）

[yanyue404]

如何成为优秀开发人员[0]：怎样算是优秀的？

文章目录

★ 引子
★ 何为优秀？
★ 本系列的目录

★ 引子

有感于国内软件开发人员的素质普遍低下，招聘程序员往往面试了 N 个人都看不到一个顺眼的（当然这里面有很大原因是教育体制的问题）。因此考虑写一个系列，聊一下"如何成为优秀的开发人员"这个话题。

★ 何为优秀？

要想成为一个优秀的开发人员，先得搞清楚什么样的开发人员才能称得上是优秀的？要给"优秀开发人员"下一个准确的定义有一点点困难，于是我用举例来说明。
　　经我多年观察，对于大部分的软件开发团队都有这样的一个现象，那就是团队中的少数（一般来说，小于总人数的 20%）开发人员具有更快的开发效率、更好的程序设计、更好的代码质量、更善于 debug、更能够解决技术难题......（总之就是让 team leader 事事省心）。而且这一小撮开发人员的贡献总和可能与另外那一大撮人（大于总人数的 80%）的贡献总和不相上下（甚至可能超过）。那么，这一小撮开发人员，就是我所谓的优秀开发人员。（跑题一下，实际上这就是二八原理的一种生动体现，请看二八原理系列的帖子）
　　说到这里，列位看官应该明白我所指的"优秀开发人员"是什么样的了吧？（如果个别读者还是不明白，那只能说明你智商偏低，本系列帖子不适合你）
　　如果你觉得自己目前还不属于这一小撮之列，但是希望自己日后成为他们中的一员，你该怎么做呢？我的建议就是：仔细阅读后续的"如何成为优秀的开发人员"系列文章。我会在里面逐一介绍相关的东东，或许有助于你能力的成长。
　　反之，如果你自认为已经完全符合我所说的优秀开发人员，那么恭喜你，你可以直接略过该系列文章，去看点别的什么东西吧 :-)
　　本系列不会涉及到具体的编程语言技巧、不会涉及到具体的开发工具、不会涉及到具体的软件框架、不会涉及到任何当下时髦的概念（比如什么 OOP、FP、Pattern、SOA、REST、RIA......）。至于我具体会聊些啥，大伙看了以后就知道了。
　　最后补充声明一下：这里所说的优秀开发人员和开发大牛（洋文叫做 Guru）不是一回事，看完这个系列文章或许有助于你成为优秀开发人员，但并不能帮助你成为开发大牛。

★ 本系列的目录

为了方便阅读，把本系列帖子的目录整理如下：
1. 关于兴趣
2. 关于自学能力
3. 设定个人发展目标
4. 做正确的事
5. 正确地做事（概述）
6. 正确地做事（善用工具）
7. 正确地做事（善用自动化）
8. （未完待续）

[yanyue404]

如何成为优秀开发人员[1]：关于兴趣

上一篇帖子已经给出了"优秀开发人员"的定义，那么现在我来说说成为优秀开发人员的头一个重要因素：兴趣。
　　因为物理学超级大牛爱因斯坦曾说过：兴趣是最好的老师。俺对此深以为然。所以咱们先从兴趣这个话题聊起。
　　兴趣这玩意是心理学层面的东西，据说人在本能上有一种"构建"的快感（例如小朋友喜欢搭积木就是）。有些人天生喜欢写程序，就是因为能够从中体会到构建的快感。鉴于心理学不是本博客重点关注的话题，暂不再深入聊下去。
　　（本文写完 6 年之后，俺又另外写了一篇《什么是【真正的】兴趣爱好？以及它有啥好处？》，供大伙儿参考）

有兴趣的开发人员和没兴趣的开发人员，差别怎么就这么大捏？这主要是因为有兴趣的人，比较有动力去学习新东西、碰到新鲜玩意喜欢去刨根问底、碰到有开发过程的困难（比如一些难调试的 bug）也显得比较有耐心、......久而久之，两种人的差别就渐渐地体现出来鸟。
　　所以，如果你属于下列情况之一：
　　　　 1、即将进入学校学习软件这门专业
　　　　 2、已经从学校毕业，即将入这个行当的新手菜鸟
　　　　 3、已经工作了若干年，但还不属于优秀开发人员
　　　　 4、已经在其它行当工作了若干年，觉得软件这行不错，想转行过来
　　并且企图在将来成为一个如我所说的优秀开发人员，那么你首先要判断一下，自己是否确实喜欢软件开发。

用如下简单的问题就能够判断出你是否确实喜欢软件开发：

假设有两个工作岗位 A 和 B 供你选择。
工作岗位 A：你可以随意地去干除了软件开发之外的任何事情（只要你喜欢的，都可以）；
工作岗位 B：你必须全职从事软件开发，不能干其它事情。
并且岗位 A 的收入比岗位 B 高很多。

对上面这个问题，你会选择哪个工作岗位？如果你毫不犹豫（其实稍微犹豫一下也没太大关系）地选择 B，那么恭喜你，你确实对软件开发非常热衷。我建议你把"如何成为优秀的开发人员"这个系列的帖子都看完，对你会有帮助。

看到这里，可能有读者要问了：如果我原先对软件开发兴趣不大，有什么方法能让我变得对软件开发非常热衷？
　　想回答这个问题，大伙先要明白这样一个事情：根据心理学（不好意思，又扯上心理学了）的研究，大部分人的性格、兴趣、气质等因素，大都形成于20 岁左右之前。在20 岁左右之后，一般不会有太大的改变。
　　所以，你如果已经从学校毕业，又工作了若干年，那么你的兴趣多半已经定型，改变的机会和效果不大（但也不是绝对不可能改变）。兴趣这种东西是自然形成的。依靠主观愿望去改变自己或者别人的兴趣，最终的效果并不理想。与其这样，不如找一个自己真正感兴趣的行业去做。
　　反之，如果你年龄尚小（不到 20 岁），还在读中学（甚至小学），那你现在还不必考虑"如何成为优秀开发人员"这个问题。在这个年龄段，重要的是发现自己的兴趣点在哪里，并让它充分发挥出来。

关于兴趣的话题就聊到这里，下一个话题咱们来聊聊"自学能力"。

[yanyue404]

如何成为优秀开发人员[2]：关于自学能力

文章目录

★ 自学的重要性
★ 自学的主动性
★ 自学的常用招数

通过本系列上一篇帖子，你应该已经搞清楚自己是否【确实】有兴趣从事软件开发工作。现在我们来聊一下开发人员的自学能力（终于开始介绍实质性的东东了）。

★ 自学的重要性

　　为啥我把"自学能力"排到"兴趣"之后捏？因为大伙儿都明白，IT 这行知识的更新速度巨快。有很多新玩意儿在你读书的时候还没有发明出来呢？退一步讲，即使某个新技术在你上学的时候已经发明出来，你的计算机老师也未必会教你（或许他/她自己也不懂）。再退一步讲，即使你上学时的计算机老师比较牛，会把当时新出来的某个技术教给你，但是你将来工作中需要用到的新技术未必就当年老师教给你那个......
　　上面啰嗦了一大堆，无非想说，你工作中终归会需要用到某个新技术是你以前没学过的。所以，自学能力是非常重要滴。以此相对照的是：国内的大多数开发人员都比较缺乏自学能力（这个也跟国内的教育体制有关）。所以，对于立志成为优秀开发人员你，需要先搞定自学能力这个东东。

★ 自学的主动性

　　我把国内的开发人员按照自学的主动性不同，分为如下几类（你顺便想想自己属于哪一类）：

◇ 抗拒自学者

这类人不愿意自学（部分人是由于懒惰、另一些是由于抵触新事物）。当工作中要用到某项新技术而需要自学时，他/她就找若干理由推诿。我估计这类人占的比例不多，万一你正好属于这种人，那还是趁早改行，别在这个行业浪费青春了（因此也别再继续看这个帖子了）。

◇ 被动自学者

这类人平时没事不会想到去自学新东西。只有当上司逼着他去学某某技术，他才勉为其难地去学。我建议这类人也不用继续看这个系列的帖子了，找个凉快的地方呆着去吧。

◇ 需求驱动型自学者

这类人自学的动机和方向是基于需求驱动。比如因为工作中要用到 XX 框架、XX 库、XX 软件，然后就利用业余时间找资料去看。如果你属于这类人，就得考虑考虑向第 4 类人转型。

◇ 计划型自学者

这类人自学的动机和方向是基于自己的规划。【定期】看看自己的知识结构有什么缺陷、将来自己想朝什么方向发展、最近哪个新东西将来会用得上 ......然后给自己定一个学习计划。
　　如果你属于这类人，恭喜你。

★ 自学的常用招数

　　现在，咱们来聊聊和自学有关的几个【常用】招数。

◇ 搜索引擎

由于使用搜索引擎是互联网时代的必备基本功，搜索引擎的重要性我就不多废话了（千万别跟我说你还不懂得用搜索引擎啊）。

◇ 百科类网站

此处所说的"百科类"例如：中文维基百科、百度百科 ...
　　百科类网站，顾名思义，就是拿来当百科全书使的。当你听说某个时髦的新术语，但又不甚了解，这时候就可以用上百科类网站了。各种专业术语一般都可以在百科类网站上查到比较具体的解释。不过百科类网站的功能也就仅限于此，当你需要深入了解某个技术时，它是远远不够的。

◇ 订阅"BBS、Mailing List、Blog"

这 3 种东东的特点是具有一定的交互性，而且大都支持软件订阅。通过订阅一些专业的、针对某个领域的"BBS、Mailing List、Blog"，你可以了解该领域的实时动态、了解该领域的热点话题、了解该领域的发展方向。你自己如果碰到疑难杂症，还可以在上面找人问（运气好的话还能交几个朋友）。
　　为啥我特地强调【订阅】捏？因为使用订阅可以让信息自动跑到你面前，省去了打开浏览器挨个访问网站的麻烦（因此也节省了时间）。这 3 种东东的局限性是：难以通过它们【系统性】地掌握某个比较复杂的技术（比如你要学习某个有一定复杂度的编程语言）。

◇ 看书（包括电子书和纸版书）

当你要系统性地掌握某个比较复杂的技术时，首选方法是：找一本针对性的好书。由于每一个具体的领域，都有 N 本书可供选择，这时候如何取舍就非常重要。如果你选的书比较差，不但看起来吃力，甚至会把你带到沟里。这时候你就得利用搜索引擎或者专门的网站（例如豆瓣、亚马逊）来识别好书与坏书。关于如何鉴别一本书的好坏，我在帖子《如何选择 IT 技术书籍》里有深入讨论，这里就不再啰嗦了。
　　再来说说电子书和纸版书。首先电子书的资源非常多，大部分国外出版的 IT 书都可以在 Internet 上找到免费的电子版。另外还有电子书还有如下好处：便于携带、能全文搜索、能共享、能备份、还省钱。从目前的发展趋势看，电子书占据主流地位只是一个时间问题。基于上述理由，所以我很喜欢看电子书（可惜大多数人都没有看电子书的习惯）。你如果还没有形成看电子书习惯的话，要开始培养了。
　　说完电子版和纸版，再来聊聊中文版和英文版。英文版相对中文版的优势就如同电子版相对纸版的优势一样明显。国内懂开发又文笔好的 IT 作家寥寥无几，导致国内出版的 IT 技术书籍要么翻译国外（翻译过程一般会导致 1-2 年的滞后、翻译质量还未必好），要么粗制滥造。所以，你如果不能流利地阅读英文书，赶紧恶补英语吧！

上述 4 个招数，如能熟练运用，从此自学无忧矣！

下一个话题，准备聊一下"设定个人发展目标和计划"。

[yanyue404]

如何成为优秀开发人员[3]：设定个人发展目标和计划

文章目录

★ 个人发展目标
★ 个人发展目标的三种类型
★ 个人发展计划

大部分人从来没有【明确】地设定自己的发展目标，每天都是得过且过。等到几年过去了，才发现自己这些年啥也没学会，还是老样子，然后就感叹时光飞逝、岁月如梭。
　　因此，今天我们来聊一下如何设定个人发展目标。（如果你平时已经很善于定期设定个人发展目标并执行得很好，恭喜你，那么本帖子你可以略过）

★ 个人发展目标

　　先说说什么是【个人发展目标】。顾名思义，就是和你个人的职业发展有关的目标，包括知识、技能、工作岗位等都可以被设定为个人发展目标。（由于本博客主要关注 IT 方面，因此我会以个人的技术发展为例来说明，但是这些方法也适用于其他方面，例如个人财务目标）

★ 个人发展目标的三种类型

我一般会把个人发展目标分为"长、中、短"三种类型，以此来对应不同的时间阶段。不管是哪种类型的目标，都要做到如下：
1. 要把目标设置得【难易适中】。太容易的目标对自己的成长帮助不够大；而太难的目标则容易中途放弃或者超出时间（导致打乱计划）。
2. 设定的目标要尽量容易评估（否则到时候连自己也搞不清楚到底目标算不算已达到）。

◇ 短期目标

先说说短期目标。短期目标的时间跨度大约在几个星期到一个季度之间。短期目标要定得比较具体，便于自己评估目标是否达成。
　　下面举几个短期目标的例子："在本月读完《Thinking in C++》"、"在本月熟悉 Spring 框架"、"在这 2 个月用 C++ 写一个五子棋游戏"......

◇ 中期目标

然后说说中期目标。中期目标的时间跨度大约在几个季度到 1-2 年。中期目标比短期目标更抽象，且必须是短期目标的有机结合。
　　比如有个短期目标是"本周看完《Dive into Python》"，那么对应的中期目标可以是"1 年内成为熟练的 Python 程序员"。

◇ 长期目标

最后谈谈长期目标。长期目标同样也必须和中级目标沾边，它的层次当然更高，时间跨度大约在 5 年以上。
　　而且长期目标一般不会关系到具体的 XX 语言、XX 平台等，倒是经常和职业岗位有一定的关联。比如"5-7 年内成为技术总监"、"5 年内成为公司产品的架构师"等。

★ 个人发展计划

　　当你把 3 种目标都设定好之后，就形成了【个人发展计划】。既然是计划，你就得在每一个阶段结束时自己总结一下，评估一下该目标的完成情况好不好，有什么收获、有什么经验教训。必要的话还需对尚未开始的后续目标进行一下调整。定期回顾还有一个好处，就是能获得一种满足感，从而有利于你坚持完整个计划。
　　关于"设定个人发展目标和计划"，今天就聊这么多。不管你是尚未毕业的在校生，还是已经工作多年的老员工（亡羊补牢还不晚），【从现在开始】，按照我上面说的，赶紧计划一下吧！

下一个话题，打算聊一下"做正确的事"。

[yanyue404]

如何成为优秀开发人员[4]：做正确的事

文章目录

★ 一些不好的习惯
★ 如何克服？

一般来说，优秀的开发人员往往具有较高的效率。俺这里提到的【效率】包括两方面："做正确的事"和"正确地做事"。并且"做正确的事"比"正确地做事"更加重要。

★ 一些不好的习惯

　　咱们先来看一些反面教材。据相关研究机构统计，大部分人（80%以上）具有如下【不好】的工作习惯：

先做自己喜欢的事情，再做自己不喜欢的事情
先做紧急的事情，再做不紧急的事情
先做容易做的事情，再做不容易做的事情
先做自己了解、熟悉的事情，再做自己不了解、不熟悉的事情
先做有趣的事情，再做枯燥的事情
先做易于告一段落的事情，再做不易于告一段落的事情
先做自己熟悉的人托付的事情，再做自己不熟悉的人托付的事情

★ 如何克服？

◇ 评估权重

你仔细回想一下，自己是否有上述的坏毛病？（我相信大多数人都有）如果你有其中的几项的话，你平时会很容易被琐事纠缠，白白浪费不少时间，每天忙完了都不清楚忙些啥。那怎么改变这种局面捏？听我细细道来。
　　"做正确的事"的关键在于评估你准备做的每件事情的【权重】。权重来源于这件事情对于达成目标是否有帮助？帮助有多大？
　　（咱们在本系列上一篇帖子《设定个人发展目标和计划》已经谈到如何设定目标）
　　如果某个事情对目标的帮助越大，则此事的权重越大；反之亦然。

◇ 严格按照权重执行

然后，每天醒来，你都要把当天准备做的事情根据权重排好优先级，然后【严格】按照优先级顺序执行。
　　如果工作中偶尔碰上看起来紧急的突发事情，也【不要】轻易改变原先安排的计划表，而要先冷静评估一下这个紧急的事情的权重。只有属于紧急且权重高（重要）的突发事件，你才可以调整计划，把这件突发事情加入其中。
　　关于重要性和紧急性的平衡与处理，在杜拉克的名著《卓有成效的管理者》中有详细的介绍，大伙儿如果有兴趣可以去看看。
　　上面说的这些，看起来简单，但是真的操作起来挺难的。能否修炼成功得看各自的造化了。一般来说，【理性】的人比【感性】的人胜算更大。如果你是一个感性的人，那更得多努力了。

聊完了"做正确的事"，下一个话题说一说"正确地做事"。

[yanyue404]

如何成为优秀开发人员[5]：正确地做事（概述）

从上一个帖子"做正确的事"写完到现在已经过去 2 周了，有网友已经等不及，在评论中催我了。在此向等待本系列的网友致歉。
　　和"做正确的事"相对应，"正确地做事"主要讨论的是有关工作【效率】和工作【质量】的关系（也就是如何"多、快、好、省"地完成工作）。由于"正确地做事"这个话题比较大，涉及到几个不同方面的【方法论】，考虑了很久，感觉一个帖子难以全部写完（俺不喜欢写长篇大论的帖子）。最后决定搞个【子系列】，针对每个方面写一个帖子。
　　如果你是一个在校的学生或者刚入行的新手，这个"子系列"应该对你很有帮助；如果你是一个团队的小头目（Team Leader），你可以根据这个"子系列"来培训你手下的新员工。

为了便于阅读，把和"正确地做事"有关的帖子目录列在下面：
1. 善用工具
2. 善用自动化
3. （未完待续）

[yanyue404]

如何成为优秀开发人员[6]：正确地做事（善用工具）

文章目录

★编辑器
★源代码管理工具（版本管理软件）
★用于调试/测试的运行辅助工具

　　俗话说"工欲善其事，必先利其器"，今天我们来说说和开发工具有关的话题。由于开发过程中会用到的工具多种多样，根据"二八原理"，我只挑选和开发最密切相关的少数几种工具来聊一聊。

★编辑器

　　编辑器显然是用的最频繁的工具了（尤其是对于经常写代码的人），但是很大一部分人不善于使用编辑器。因此我先来说一下对编辑器使用的一些体会。顺便提一下，如果你连盲打都没过关，请先去学打字，再回来看这个帖子。

◇字体

　　对于写代码而言，字体的选择是非常重要的（看起来舒服的字体起码能保护眼睛）。首先必须选择一种【等宽】的字体（比如 FixedSys、Courier New）；其次该字体必须能够【清楚地区分】如下几种容易混淆的字符，避免阅读代码的时候看错：

数字0　和　字母O
数字1　和　大写字母I　和　小写字母l　和　或运算符|
数字2　和　字母z
数字9　和　小写字母q
乘号*　和　字母X
分号;　和　冒号:

◇颜色

　　你使用的编辑器必须支持【自定义】的词法高亮（词法着色）。
　　对词法高亮进行设置时，至少要把："代码注释、关键字、字符串、数字"这几种语法要素用不同的颜色区分开。当然，如果还能根据"类名、函数名、变量名等"进行着色，那就更好了。

◇快捷键

　　熟练地使用快捷键能大大提高编辑的效率。因为你的手不需要离开键盘去操纵鼠标。而且当编辑的文本比较大时，有些编辑命令即使用鼠标操作也挺费劲（比如全选、移动到文件尾），不如快捷键方便。
　　所以，你使用的编辑器必须支持快捷键（这个大多数都能做到），而且还必须支持编辑命令和快捷键的绑定（也就是自己设置某个编辑命令对应的快捷键），便于根据个人喜好设置快捷键。

◇其它功能

还有一些比较琐碎的功能，比如：代码自动缩进、自动补全、动态提示等等。最后，如果你需要经常在不同的操作系统上进行工作，那你的编辑器还必须得支持跨平台才行。
虽然说了这么多条条框框，但是符合全部要求的软件并不难找，比如Emacs、VIM、Eclipse等软件都可以满足上述的编辑功能，具体选哪个就看各自的偏爱了。

★源代码管理工具（版本管理软件）

　　为了打字方便，以下简称"RCS"（Revision Control System）。
　　通过 RCS 的使用状况，可以看出一个开发团队在软件工程方面的成熟度，因此我们接下来要说说 RCS 的问题。如果你所在的开发团队从来不使用 RCS 进行代码的版本控制，那俺建议你赶紧考虑跳槽。
　　据俺多年的观察，发觉 RCS 主要有如下几种误用的情况：

◇不正确的提交频度

　　有很多新手不习惯使用 RCS，很少进行代码的提交。有些人甚至到项目快结束时还没有提交过一行代码。结果导致整个 RCS 形同虚设。
　　还有一些人则走向另一个极端，频繁提交代码。有些人每改完一个文件就提交一次，还有些人甚至把修改一半，尚【不能】编译通过的代码也提交到 RCS。
　　俺个人认为，正确的提交频度应该分两种情况：在编写功能代码时，每完成一个功能点，并且自己经过了自测之后，提交一次；在调试的时候，每修复一个 bug，提交一次。这样能够保证提交到 RCS 的代码都是【能编译通过】的（详见每日构建系列），并且业务逻辑上也是相对完整的（对于每日构建后的测试很重要）。

◇提交时不写注释

　　很多人提交代码时不写注释，将来再想到版本历史里面找代码就犹如大海捞针般困难。
　　比如在俺经手的代码中，有些源代码文件历时3年，提交次数上百次，如果提交时不写注释，日后根本没法找。

◇不做代码基线（Baseline）、不做代码分支（Branch）

　　在正规的开发团队，每当有一个版本发布（Release）并交付给用户使用时，都需要在 RCS 中制作一个基线，以便于进行相应的 bug 跟踪和补丁制作。因此，诸如【做基线】之类的事情，属于整个团队的集体行为，需要由 Team Leader 牵头来搞。
　　假如一个开发团队从来不做代码基线或者代码分支，仅仅是把 RCS 当成一个源文件的备份工具来用，那至少说明这个团队的 Team Leader 在软件工程管理方面非常失败。

★用于调试/测试的运行辅助工具

　　运行辅助工具对于开发效率的影响也很大。一般来说，你自己的开发机器上要有尽可能仿真（和用户的环境相似）的运行环境，并且运行辅助工具能够有效地发现运行时的一些不正常的信息。这样有利于让 bug 在交付给用户之前【尽早暴露】出来。
　　如果你是 Web 开发人员，那么你自己肯定要安装好常用的浏览器（至少包括 IE、Firefox、Chrome）。对于 IE，还得设置成"显示脚本错误通知"。
　　如果你主要开发 Windows 应用程序，你手头肯定要备好诸如：Depends（Visual C++自带）、Process Explorer等工具，便于查看进程、线程、动态库、堆内存等运行时信息。
　　如果你是搞手机应用的，那么你至少得有目标系统的模拟器软件（如果能配一个真机当然更好）。
　　如果你主要进行跨平台方面的开发，那么诸如"VMware / VirtualBox"之类的虚拟化软件是必不可少滴（关于这类软件，俺写过一个系列：《扫盲操作系统虚拟机》）
......

　　限于篇幅，今天就只说这些。其它我未提及的工具，大伙儿自己可以举一反三。下一个话题，打算说说"善用自动化"。

[yanyue404]

如何成为优秀开发人员[7]：正确地做事（善用自动化）

文章目录

★"自动化"的重要性
★实现"自动化"的例子
★人肉自动化

　　上一个帖子聊了"善用工具"的话题，讲的都是如何有效利用工具来提高效率，今天说一下如何利用"自动化"来提高效率。

★"自动化"的重要性

　　隐约记得 Perl 语言的创始人Larry Wall 曾经评价过程序员的三大美德，分别是：【懒惰、急躁、傲慢】。（刚才找到原文在这里）在这三大美德中，"懒惰"赫然排在第一，可见其重要（另外，马云似乎也说过类似的名言）。
　　俺对他所说的"懒惰"是这样理解的------就是干尽量少的活，但是依然保质保量地完成工作。那么，如何才能偷懒捏？一个有效的办法就是【自动化】。
　　俺这里说的"自动化"，当然不是大学里自动化专业的那个"自动化"，而是指：利用各种方式（主要是计算机）来帮你【自动完成】某些（枯燥、费时、无价值）的重复劳动；然后你就可以利用节省出来的时间，干一些更有意义的事情了（比如学习点有用的东西）。
　　具体该如何做呢？要实现自动化，首先就要观察你平时做的事情中，有哪些属于【重复】劳动；然后评估一下这些重复劳动是否可以用某些工具来替代；如果有可能替代，你就可以动手把这个工具实现出来，然后就可以让工具来帮你做事情了。
　　说了这么多，感觉有些抽象，下面我举几个方面的例子来给大伙儿加深一下印象。

★实现"自动化"的例子

◇Blog 订阅

　　如果你经常看俺的 Blog，但是没有使用 Feed（RSS） 订阅工具，那你就要当心了。你属于不善于利用自动化的人。
　　使用了 Feed 订阅工具，你就不需要经常访问某个 URL 的页面去看有没有新帖子。因为这个枯燥的重复劳动已经由订阅工具帮你【自动完成】了。你所要做的，仅仅是在订阅工具中初始化某个 URL（只要做一次），然后订阅工具会在有新帖子的时候通知你。所以，除非你要发评论，否则不需要访问俺博客的页面 :-)

◇调试程序

　　估计看俺 Blog 的同学，大部分都有过调试程序的经验。当程序行为不正常时，经常需要设置断点，然后单步跟踪代码，以便找出程序出错的源头。其实这个过程也有大量的重复劳动。
　　俺一般喜欢通过程序断言（以下简称 assert）来简化上述过程。看到这里，有些同学心里犯嘀咕了：程序断言和自动化有毛关系啊？其实每一个 assert 就好比一个【自动的】代码检查点，【每次】程序运行到 assert 处的时候，如果你设置的逻辑条件不成立，它会立即终止程序并打印出相关信息（比如函数调用栈、文件行号等）。
　　如果你在写代码的时候，经常在一些【关键点】设置一些【条件恰当】的 assert，可以大量节约调试时间。俺自己写的程序，在自测的时候，有70%-80%的逻辑错误会被 assert 暴露出来，所以改起来非常快；测试人员提交给俺的 Bug，大概也有一半以上可以通过 assert 快速定位出错误的源头。

◇自动化测试

　　说完了程序员的例子，再来说一下测试人员（其实我在"每日构建：流程"已经稍微提到了测试的自动化）。俺发现很多公司的测试人员，重复劳动特别严重。他们不断地重复做一些软件功能的验证操作；发现bug后通知程序员改；程序员改完，再次进行验证操作......如此循环往复。N年之后，这些测试人员的个人能力没啥提高，年龄倒大了不少。
　　在此，俺强烈建议测试人员：尽量多使用一些自动化测试工具（比如 QTP）和一些测试脚本来完成上述的软件功能验证操作。不光能节约很多时间，提高了效率；而且在自己编写测试脚本的过程中，或许还能学些新东西，提高一下个人能力。比如俺见过一个测试人员，由于经常用Python写一些脚本进行网络和数据库方面的测试，久而久之，写 Python 脚本的水平很熟练，然后就被转去做 Python 开发。

★人肉自动化

　　上面说的自动化都是技术层面的（都是靠软件实现）。为了给大伙儿扩展一下思路（免得思维定势），最后来说一下非技术的例子。
　　比如部门中经常有人出差，每次出差都要都要订机票。订机票就属于重复劳动，而且挺繁琐。得去网上查航班、还得看哪个航班折扣优惠、选好航班还得付钱，然后去机场还得打印行程单，出差回来还得填写报销单（报销单还得找N个人签字），然后拿着报销单与行程单找秘书报销。这些琐事累加起来，少说也得一个小时才能搞好。
　　为了提高效率，把上述这些琐事统统都交由秘书搞定。出差的家伙需要做的就是发一个邮件告诉秘书，要订某天某时的飞机到某地，就一切 OK 了。经过这样改革，部门里的人（除了秘书）都皆大欢喜。