# 二十三、任务换人有害无益
在管理一个程序团队时,第一件要学的事就是任务配置(task allocation)要正 确。「任务配置」只是把事倩分丈家微的夸大说法。用希伯来文的普通话来 说就是「倒档案」(因为你会把档案倒在某人身上)。有些事情做得对会得到不可 思议的生产力利益,决定哪些档案要倒在谁身上就是其中之一。反过来没做好 的话可能就会陷入麻烦的状况,没有人能做好何任何事情而且大家都抱怨「在这 里什么事都做不起来。」 由于这是个针对程序员的网站,我要拿个程序设计问题让你的脑袋动一动暖暖身。
假设你要做A和B两件运算要做。每一件都需10秒的CPU时间。现在你有一颗CPU, 为了简化问题,所以工作序列中没有其他东西。
在我们的CPU中可以选择是否用多任务处理。所以你可以先做好一件再做另一件。
循序处理
![](https://box.kancloud.cn/2015-12-28_5681031e638dc.png)
也可以使用多任务方式。如果用多任务的话可以假设这颗特别的CPU每个工作每 次可以执行一秒,而且工作切换完全不花时间。
多任务处理
![](https://box.kancloud.cn/2015-12-28_5681031e777fa.png)
你会选哪一种方式呢?大部份人的直觉反应都认为多任务比较好。不管哪一种状 况,都得等20秒才能两件运算都完成。不过可以想想单就各洋运算来说要多久才 有结果。
在两种状况下,运算B(标成蓝色)都要20秒才得到结果。不过运算A的结果在多任 务时需要19秒。可是循序时就只要10秒就好了。
换句话来说在这个安排好的例子中,循序处理的每洋运算游f均对/琢比多任务处 理少(15秒对19.5秒)。(事实上这例子也并不是真的那么假–它是源于Jared在工作中必须解决的一个真实问题)
| 方法 | 运算A花的时间 | 运算B花的时间 | 平均 |
| --- | --- | --- | --- |
| 循序处理 | 10秒 | 20秒 | 15秒 |
| 多任务处理 | 19秒 | 20秒 | 19.5秒 |
我刚刚说过「工作切换完全不花时间」。其实在真的CPU中工作切换是需要一点 点时间的,基本上要足够储存CPU缓存器的状态并加载其他工作的CPU缓存器。实 际上这短到几乎可以忽略。不过为了让生活更多乐趣,让我们假设工作切换需要 半秒。现在情况变得更糟了:
| 方法 | 运算A花的时间 | 运算B花的时间 | 平均 |
| --- | --- | --- | --- |
| 循序处理 | 10秒 | 20秒 + 1次工作切换 = 20秒 | 15.25秒 |
| 多任务处理 | 19秒 + 18次工作切换 = 28秒 | 20秒 + 19次工作切换 = 29.5秒 | 28.75秒 |
现在呢,虽然我知道这有点蠢,不过就算为了让我高兴一下,想想如果工作切换需要一分钟那如何?
| 方法 | 运算A花的时间 | 运算B花的时间 | 平均 |
| --- | --- | --- | --- |
| 循序处理 | 10秒 | 20秒 + 1次工作切换 = 80秒 | 45秒 |
| 多任务处理 | 19秒 + 18次工作切换 = 1099秒 | 20秒 + 19次工作切换 = 1060秒 | 几近19分钟!! |
工作切换用的时间愈长,多任务处理的代价愈大。
这件事本身不怎么新奇,不是吗?不久大概就会有些白痴气愤地写信指控我「反 对」多任务处理了。他们会质问我:「你真的想要回到那种得先结束WordPerfect 才能执行Lotus 1-2-3的DOS时代吗?」
不过那并不是我的意思。我只是想要你同意,在这类例子中:
a)循序处理会让结果次上比较快得到,而且
b)工作切换需要愈久,多任务处理所付的代价就愈大。
够了,别管CPU 了,来管管人吧,这有趣多了。这里的重点在于管理「程序员」 时,工作切换会需要很长很长的时间。因为程序设计这种工作必须同时在脑袋 里记很多东西。另外记住的东西愈多,写程序时生产力愈高。用全速写程序的程 序员脑里随时都会记住无数的事情:变量名称,数据结构,重要的API,写过常要 用到的辅助函数名称,甚至存放原始码的次目录名称,一切东西都要记住。如果 你把程序员送到克利特岛去度假三星期,他所存东西通通都会忘掉。人脑似乎会 把东西移出短期RAM,改存到永远都读不回来的备份磁带上。
要多久呢?嗯,我的软件公司最近放下手头上在做的事(开发一套代号CityDesk 的软件产品),花了三星期去帮助某个客户处理一个紧急状况。当我们回到办公 室时,感觉好像要另夕A三星期才能回复全速制作CityDesk。
就个人层次来说,你曾经注意过某件事吗?叫某人做一个工作可以做得很好,可 是如果给他两个工作,他会把其中一个做好却忽略另一个,不然就是两件工作都 做得很慢,慢到你觉得#龙蜜都比他勤劳。这是因为程序设计的工作就是需要很长 的切换时间。就我自己来说,当我需要同时完成两个程序设计项目时,切换时间 大概要六个小时。以一天八小时来看,等于说多任务处理把我的生产力降到每天 只剩二小时。真令人沮丧啊。
同样的道理,如果你给某人两件工作,应该要感谢他们只做一件工作而放弃 另一件,因为这样能做好更多的事,而且平均上也能更快完成工作。事实上这一 切的重点就是绝对不要让人同时做一件以上的事。请确定你有明白它的意思。好 的经理人会认为自己的责任是濟餘摩涛,好让大家都能专注在一#事倩并把它真 的完成。遇到紧急状况时,请先想想能不能自己处理掉,真的不行再丢给深陷在 专案中的程序员吧。
- 第一部分 位与字节:编程实践点滴
- 一、语言的选择
- 二、深入底层
- 三、joel测试:改进代码的12个步骤
- 四、每一位软件开发人员必须、绝对要至少具备UNICODE 与字符集知识(没有任何例外!)
- 五、轻松写就功能规格说明书 - 第1节:为什么烦心?
- 六、轻松写就功能规格说明书 - 第2节:什么是规格说明书?
- 七、轻松写就功能规格说明书 - 第3节:但是……如何?
- 八、轻松写就功能规格说明书 - 第4节:技巧
- 九、轻松制订软件进度表
- 十、每日连编是朋友
- 十一、难伺候的故障修复
- 十二、软件开发中的5个世界
- 十三、稿纸原型开发
- 十四、不要被太空架构师所吓倒
- 十五、开火与运动
- 十六、人员技能
- 十七、源于计算机学科的三个错误思想
- 十八、二元文化
- 十九、自动获取用户故障报表
- 第二部分 开发人员的管理
- 二十、面试游击指南
- 二十一、重金激励害多利少
- 二十、二不配备测试人员的五个首要(错误)原因
- 二十三、任务换人有害无益
- 二十四、绝不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序设计界的LordPalmerston
- 二十八、评测
- 第三部分 Joel对常态问题的遐想
- 二十九、RickChapman解读愚昧
- 三十、在这个国家狗是干什么的? 我们有多么天真?
- 三十一、作为哼哈二将,只管去做事
- 三十二、两个故事
- 三十三、巨无霸麦当劳与天才厨师JamieOliver
- 三十四、没有什么像IT看起来那么简单
- 三十五、提防非自主开发综合症
- 三十六、策略I:BEN&JERRY公司与AMAZON
- 三十七、策略II:鸡与蛋问题
- 三十八、策略III:让我回去!
- 三十九、策略IV:大件与80/20神话
- 四十、策略V:公开源代码的经济因素
- 四十一、墨菲法则肆掠的礼拜
- 四十二、微软公司是如何败北API之战的
- 第四部分 对.NET稍多的评说
- 四十三、微软精神失常了
- 四十四、我们的.NET对策
- 四十五、请问,我可以使用连接程序吗