《joel说软件》
内 容 简 介
这是一本介绍软件管理的小品文集。全书分为45章，每章就是一个独立的专题或者知识点。本书内容十分丰富全面，小到项目负责人制订进度表，大到软件执行总裁提出富有竞争性的战略，都在本书的介绍之列。尽管内容很多，但事例驱动的写作方式，奠定了本书在可学性与可用性方面明显的优势。
本书从不同侧面满足了软件开发人员、设计人员、管理人员及从事软件相关工作的人员的学习与工作需要。
Joel Spolsky，软件行业的一位老兵，开办了一个叫做“Joel说软件”（www.joelonsoftware.com）的blog网站专栏。这是在程序员当中最为流行的独立网站之一。该网站被描述为“反Dilbert宣言书”。Spolsky设计与开发的软件拥有数以百万计的用户，他参与研发的软件是各种各样的，从Microsoft Excel到Juno用户界面。此外，他在纽约市创建了Fog Creek软件公司。
你可能从来没有奢望自己成为一名经理。像我所知道的大多数软件开发人员一样，要是能够让你坐在那里安安静静地写代码，你就会感到由衷地高兴。不过，作为一名最优秀的开发人员，在小组老领导Nigel出了那场不幸的包装绳与笔记本电脑事故之后，你晋升为小组的主角似乎显得顺理成章了。
这样一来，现在你有了自己的办公室（而不是与整日待在房间里的暑期打工仔共用一间卧室），并且必须去填写每年两次的业绩评估表（而不是整天两眼盯着CRT乐此不疲）。也就是说，现在不用浪费时间去处理女首席程序员提出的奇怪要求，应付拍肩膀的推销员，以及倾听充满创造力的“用户界面设计人员”（因为Pete之故，他们是作为图形设计人员而录用的）。这些设计人员想凸现有反射光的亮丽的“OK/ Cancel”按钮。我想知道，“反射光”的RGB值是多少？另外，还要应对高级副总裁的空洞提问，他所知道的关于软件的一切知识来源于Delta航班的旅途消遣杂志文章。“我们为什么不用Java，而要用Oracle？我听说它显得更为统一！”
欢迎进入管理世界！猜想到什么了吗？软件项目的管理与程序设计是完全不相干的两码事。假如到现在为止你所做的一切就是写代码，那么你会看到，人类大概比像花园里的杂草一样品种繁多的Intel CPU还要不可预测。
无论怎么说，老领导Nigel从来就不很精于此道。“我不想成为那种将所有时间都花在毫无意义的会议上的经理人员！”他用充满几分自信的口吻说。“我觉得仍然可以将85%的时间用在编写代码上面，在管理方面只花一点点时间就行了。”
Nigel真正想说的话是：“我对如何管理这个项目没有任何心血来潮的想法，也不会像我以前全心全意编写代码的时候充满希望，在某种程度上，一切都像自然而然地自动产生一样。”事情当然不会那么顺利发展，要切实解释在那个命该如此的日子里为什么Nigel会被IBM ThinkPad电得跳起来，会有很长的一段路去走。
不管怎么说，Nigel真的恢复得令人吃惊得好。鉴于此，他现在担任一家小公司的CTO。该公司是从难兄难弟WhatTimeIsIt.com起家的，他只用了六个月的时间就从零开始发布了一个全新的系统，他再也不能碰运气了。
软件项目管理不是一门很知名的艺术。没有人有软件项目管理的学位，这方面的书籍也很少。那些在软件项目方面真正做得很成功的稀有人物当中，有许多人在有机会将自己积累的经验传给下一代之前，就很富有并隐退到养鱼场垂钓去了，另外一些人则筋疲力尽，找一份强度不大的工作，如给市内的瘪三补习英语聊以度日。
结果就是，许多软件项目以这样那样的方式，或公开，或无声地失败了，因为项目组当中没有人知道一个成功的软件项目可能是如何去运作的。于是乎，太多的小组永远无法交付他们的产品，或者交付产品的时间显得过长，或者交付的产品没有人愿意使用。不过，最让我生气的部分还是项目组的人不乐观，整日里抱怨这抱怨那。人生如此短促，没有时间去厌恶自己的工作。
几年前，我在自己的网站上提出了“Joel测试”概念，其中列举了运作良好的软件项目组表现出的12个指标。比如说，维护一个跟踪故障信息的数据库，让求职人员当场编写代码等（不要担心，后面我还要就此进行更为详细的说明）。令人惊讶的事情是，如此众多的人通过电子邮件告诉我，他们的项目组在12项测试中只能得两三分。
两三分！
太异乎寻常了——可以设想一下，几个从来没听说过螺钉是怎么一回事的木匠却试图去做家具，会是怎样一番情景！他们完全要靠钉子来干活，给木头钉钉子居然用舞鞋，因为没有人告诉他们可以用榔头。
软件项目管理需要一套与编写代码完全不同的技能和方法，它们是两个截然不同且毫不相关的领域。写代码与软件项目管理之间的差别大得就像脑外科与烤法国面饼。没有理由希望一位才气横溢的脑外科医生，因时空倒错而到一家法国烤面饼工厂，会精通烤面饼，即便他毕业于哈佛医学院。然而人们还是不可避免地认定，用不着任何调整就可以让一位顶尖编码人员去承担管理性工作。
像前面提到的那位脑外科医生一样，你和Nigel会突然感觉到自己要从事一个全新的工作，管理，需要你与——上帝啊——项目组的人员，而不是编译器进行交流。要是你认为Java编译器故障很多且不可预见，那么等着出现第一个首席女程序员问题好了。管理由人组成的队伍使C++模板看起来显得过于琐碎。
软件项目的成功管理是要有技术的。该项管理艺术目前发展的状况远远超过了钉子与舞鞋的情形。我们已经有榔头、螺丝刀与双面两用锯可用。本书的写作目的在于从各个层面尽我所知向你介绍一些方法，小到项目组负责人制订进度表，大到软件执行总裁提出富有竞争性的战略，都在该书的介绍范围内。
在本书当中，你可以学到：
如何聘用与激励最优秀的员工——软件项目成功当中惟一的最至关重要的因素。
如何评估与调度工作，以及为什么要这样做。
如何设计软件功能，撰写确实有用的规格说明书，而不仅仅是用做维修集体宿舍的“只写不看”的包装纸。
如何避免落入软件开发常见的陷阱，以及当程序员坚持按照“丢弃它而从头开始”的想法行事时，为什么总是错误的原因。
如何组织与激励项目小组，以及为什么程序员需要办公室门窗都紧闭。
即使可以从网上下载足够好用的软件版本，那么什么时候需要自己从零开始去写代码。
为什么软件项目总是在经过开头几个月的快速奔跑之后就似乎裹足不前了。
拥有好的软件策略意味着什么，以及为什么BeOS从第一天起就命中注定了灰色的结局。
其他更多的内容。
书中的内容显得有些主观，我只能如此。为了简洁起见，每句话的开头我都把“在我看来”的短语去掉了，因为实际上书中的每句话都是我的看法。这虽然不完整，但或许是一个很好的开头。
呵，如此说来，你看过我的网站了……
本书的许多内容最初是以系列文章的形式在我的网站“Joel说软件”（www. joelonsoftware.com）上发表的。那是承载我多年思想的地方。我希望你手中的这本书能够比网站更有“粘结性”，我说粘结性的意思是“你可以在浴缸里阅读而不用担心触电”。
本书分三个主要部分。第一大部分是关于开发小范围软件的所有内容：每件事情都应该由自己的团队来完成，以确保软件不会给人们带来危害。第二大部分包含关于程序员与开发小组管理方面的文集。第三部分虽然显得有点随意，但是介绍的主要精力放在构筑可行的软件开发业务大战略之上。在这里，你将了解到为什么大件总是赢得现在，为什么Ben & Jerry式公司与Amazon不一样，并且我会试图指出一种情形——存在成套的软件开发模式通常是缺乏胜任工作的员工的一种表现。
虽然在这里说了很多，但还是深入书本开始阅读为好。
第一部分位与字节：编程实践点滴
一语言的选择2
二深入底层4
三JOEL测试：改进代码的12个步骤14
四每一位软件开发人员必须、绝对要至少具备UNICODE
四与字符集知识（没有任何例外！）27
五轻松写就功能规格说明书第1节：为什么烦心？38
六轻松写就功能规格说明书第2节：什么是规格说明书？44
七轻松写就功能规格说明书第3节：但是……如何？54
八轻松写就功能规格说明书第4节：技巧58
九轻松制订软件进度表65
十每日连编是朋友75
十一难伺候的故障修复81
十二软件开发中的5个世界87
十三稿纸原型开发94
十四不要被太空架构师所吓倒96
十五开火与运动100
十六人员技能104
十七源于计算机学科的三个错误思想109
十八二元文化114
十九自动获取用户故障报表120
第二部分开发人员的管理
二十面试游击指南132
二十一重金激励害多利少145
二十二不配备测试人员的五个首要（错误）原因149
二十三任务换人有害无益156
二十四绝不去做的事情，第一部160
二十五冰川下的秘密165
二十六漏洞抽象定律172
二十七程序设计界的Lord Palmerston178
二十八评测185
第三部分Joel对常态问题的遐想
二十九Rick Chapman解读愚昧188
三十在这个国家狗是干什么的？193
三十一作为哼哈二将，只管去做事198
三十二两个故事204
三十三巨无霸麦当劳与天才厨师Jamie Oliver209
三十四没有什么像IT看起来那么简单214
三十五提防非自主开发综合症218
三十六策略I：BEN & JERRY公司与AMAZON222
三十七策略II：鸡与蛋问题230
三十八策略III：让我回去！237
三十九策略IV：大件与80/20神话242
四十策略V：公开源代码的经济因素246
四十一墨菲法则肆掠的礼拜254
四十二微软公司是如何败北API之战的258
第四部分对.NET稍多的评说
四十三微软精神失常了276
四十四我们的.NET对策282
四十五请问，我可以使用连接程序吗286
第五部分附录
