More Joel on Software 读书笔记

P4. Excel的日期函数：1900年2月29日？

无论开发操作系统还是个人网站，不要停留在API的表层，要看到它的背后。如果我是微软的Excel程序经理，我能回答Bill的“最难的问题”吗？99%的时候不能！如果我是Bill，我能在一个晚上看完500页的SPEC、在每一页上留下评注并最终问出那个“最难的问题”吗？100%不能！这就是区别。

So What? 虽然很想想当然的说：“看源码”，但如何操作真的很难。也许对于那门必须“精通”的手艺，我得看看它背后到底是什么了。

PS1. （至少在高科技领域）管理真的是通用职能吗？不懂得技术的人，真的能管好一家IT公司吗？更加现实的问题是，一个与电脑绝缘的CEO，真的能招募到一个超绝的CIO，然后让公司“信息化”吗？我深表怀疑。这好像让一个没有品位的地产商去发掘艺术家一样。尤其是在IT和其它高新技术领域，最近5年的发展足以让最近50年的成功失色，而最近10年的进步足以埋葬100年前所有的教条，对于这样的领域，口碑和多数派的意见都是毫无意义的指标！所以，最可能发生的是，多数中小型企业永远也无法招募到像样的信息化团队（因为那帮HR和C*O不知道啥是像样的IT），不过这不要紧，因为多数人都没有见过真正的好东西，所以差一点的他们也会接受。推论是什么？如果呆在一家非IT公司，我的职业发展方向究竟是什么？也许必须结束坐井观天的生活了:(

P10. 优秀的程序员是不会出现在招聘市场上的

是的，优秀的程序员（系管、DBA以及其它若干职位）不需要到处投简历。在我最近收到的一千封简历里，我从来没有找到一个100%符合要求的候选者，哪怕只是要招一个系统管理员。（必须说部分原因是如今的IT技术分化太细，几乎无法要求一个候选人符合所有的要求，除非你只是需要一个“专家”。但当你无法随身携带所有的扳手和钳子的时候，你确实需要一把瑞士军刀。这也是个令人头痛的现实，如果你要做个专家，那么如果你没能成为TOP100，那么别人不会甩你，你可能会失业；而如果你要做个通才，那么你注定拿不到TOP100的薪资……头痛）多数求职者的简历充满了各种笑料（或悲剧），有的简历甚至成了老朋友，每个星期都能看到一次（这也许就是为什么他们必须留在招聘市场的原因）。好的求职者不用到处发简历，同理，好的职位也不需要到处贴招聘启事——黑客们有他们自己的圈子，内部消化这些空缺永远都是第一选择。

P13. 走出去

所有IT人都有阿斯伯格综合征（亲爱的老板，如果你不幸看到这段话，请不要怀疑我的精神有问题，这是个比喻），总是希望只在自己住处的方圆一公里内活动。但如果你需要雇一个杀手，那你一定没有理由在社区里贴寻人启事。想象一下你需要的人会去什么地方，走出去，逮一群回来。更重要的是，既然我想获得一份好的差事（亲爱的老板，如果你不幸看到这段话，请不要怀疑我的忠诚有问题，这是个比喻……OK，其实不是），想象一下我需要变成的那种人会去什么地方，走出去……被别人逮去。

P14. 实习生

如果10年以前看到这段文字，我的人生绝对不会一样（按蝴蝶效应推理，此系废话）。不过话说回来，Joel的人才观……有远见！

P19. 建立社区*

Joel给这个方法加了个星号，表示很难。换个角度，如果你希望被人注意，加入一个社区，弄点动静出来！

P19. 员工推荐：小心陷阱

聪明的程序员一定认识其他聪明的程序员？可能确实认识，但是他们的亲密朋友中也会有人不是非常优秀的程序员……无法回避的巨大风险，就是竞业限制（Noncompete agreement）……你可能雇了一堆人，他们的前雇主都是同一家，那门你将承担非常巨大的风险……如果人事经理决定为有效的推荐提供一点奖金……突然之间，你手下的整个大军都在设法让你雇佣一个对你毫无用处的人。

PS2. 做IT的人不比别的行业聪明，但玩起逻辑则几乎所向无敌（另一类逻辑大师是律师，两者都擅长逻辑，区别在于，IT的规则是不可逾越的，你不可能通过一个另类的“诠释”来让系统从宕机中恢复过来，也不可能通过舆论来让C编译器忽略你的错误，而法律的规则虽却总能“诠释”）。所以当HR们上完MBA课程后试图“绩效奖励”，回报他们的通常总是杯具——更杯具的是这些HR们根本不会发觉发生了什么事。

P28. Hit-and-run

大多数时候我们都被上司扔在那里（同时我们也把下属扔在别的什么地方），但是偶尔他们也会介入，追问一些极小的细节（我们则介入下属的某些细节），这就是多数团队中可以看到的Hit and run。但如果你要雇佣聪明人（或你雇佣的已经都是聪明人），你就必须小心，因为不管什么技术问题，“经理们知道的很可能不如在壕沟里干活的工人们”，当你雇佣专家的时候，让他们在专业领域里去做决定，尊重他们。

P31. 使用非必要的热门新技术

嗯，接触新技术确实可以让我开心。

P32. Identity Management

世界上只有一个苹果公司。事实上，大多数公司都能有效的实施自我认同管理，只不过不是针对所有员工罢了——通常是销售部门。

P36. 军事化管理

亲密不会让士兵面对危险时挺身而出，恐惧才会。（腓特烈大帝）

IT人很自负，不愿意被管；和军队不同，IT团队每个人做的事都不一样，无法进行微观管理；将军们总比士兵知道更多的情报，而经理们知道的永远比程序员少。结论：军事化管理是为了让18岁的年轻人在地雷阵里发起冲锋，对IT团队无用。

P40. The Econ 101 Management Method

等于鼓励IT人与制度博弈。参考Measuring and Managing Performance in Organizations, Robert D. Austin.

P46. 认同法

创造一个有凝聚力的团队；向员工提供必要的信息。

P50. Java……太简单

指针、递归、函数编程，Joel坦率的说，除了那些“令人激动”的任务，大多数情况下都不需要使用它们。的确，我从来没有在单位里使用过指针（最近学Go语言，情况有变，但Go只是“具有指针”但不允许“指针运算”，所以我想Go也不符合Joel的标准，唉，复习C吧），很少用递归（一般只在元编程和有自包含结构的情况下使用），而函数式语言则根本没有使用过（但按照Joel的描述，他指的并非是纯粹的函数编程，像闭包这样的操作也被包含在其中，这样的话，Groovy是支持的，还特别好用）。但总的来说，重新审视一下C或者Haskell这样的语言，哪怕是把它们当作智力测验，也会对一个程序员有莫大的帮助吧。（也许还要学习State machine）

P61. 当程序员遇到问题的时候，他们会把问题重新定义

……使其可以用算法解决，从而把问题转化成他们可以解决的形式。但实际上解决的只是问题的某种外在形式。

P61. 务实派 vs. 技术派

考虑到边际效用递减原则，一味追求“没有错误”的代码将得不偿失。另外，规格说明书永远也不可能完美，总是存在Shannon Entropy。

P67. 内用软件

1. 永远不能用正确的方法做事（只能用最保险的）；2. 永远做不出优秀的产品（一旦一个项目可以运行了，你就得转战下一个项目，而不是精益求精）；3. 管理层永远不会依赖你。我原本以为我的战场就应该是内用软件，但现在，我觉得Joel是对的。

P77. 微观经济学

这是书里最重要的建议之一，学习它，搞清楚生意为什么是那么做的，要懂得基本的商业规则。

P88. 用户喜欢哪一种处理方法？

……反映了一个事实，如果你问人们喜欢什么样的风格和设计，除非这些人受过专门训练，否则他们一般会选择自己最熟悉的品种。引申：当我说A比B好的时候，很可能只是在说我更熟悉A而已。引申2：没事别让你的客户选择，他们会选自己以前见过的，而不是他们需要的。

P92. 微小的改进

为了发现可以改进的地方，你必须有一个思维定势，始终如一地用批判的眼光看世界。随便找一样东西，如果你看不出它的缺点，那么你的思维转型还没有成功。呃……讲那么复杂，不就是鸡蛋里挑骨头吗，我擅长。

P95. 总是觉得自己看到了全部，即使事实不是如此

在软件开发中，这是一个特别危险的陷阱……形成了一个整体的设想，想好了下一步要做什么，一切看上去都清晰无比……马上一头扎入工作……

P99. 阅读列表：

Soul of a New Machine
Show Stopper

P101. The Paradox of Choice: Why More Is Less – by Barry Schwartz

太多的选择最终限制了我们的自由，而不是解放

P119. ……不顾一切的想要逐句驳斥……

编程工作要求一个人在每个i上面点上一点，在每个t中间画上一横，所以他们形成了一种思维定势，就是绝对不能不回应争论。
这确实是我的风格，原来这种风格还有一个学名：Fisking（源于一个从来不上网并认为Email和Blog属于浪费时间的英国佬的名字）

P137. 关于鲁棒性原则

Jon Postel的Robustness Principle经常导致部署上的难题，原因是对他方的行为宽容（liberal）的后果是导致他方软件的错误暴露之前已经大规模部署，从而造成既成事实，最终导致问题被发现时已经没有合适的解决方案。
我猜想鲁棒性原则还是会被大量使用，毕竟现实中垃圾输入太多，如果坚持严于律人的话，很快就没啥活好干了。

P147. 不要试图读写Office二进制文件

使用COM自动化让Office为你干脏活；使用更简单的格式生成文件。
无论我是多么固执的Unix学派，了解COM组件的操作都是非常有必要的。（再顽固也不会比Mac Fans顽固吧。最近看了13年前Jobs重组苹果董事会时进行的演讲，讲到一半Jobs说要和MS合作，会场内立刻嘘声一片，讲到将支持IE，嘘声一片，播Gates的讲话，还是嘘声一片，但唯有宣布Office支持的计划时，全场掌声雷动。任何一个有理智的人都不会否认MS Office早已成为事实上的标准，如果你玩不转Word或Excel，那么多半在求职市场上你也玩不转。）

P156. 为什么软件开发者不太愿意做日程规划

第一个原因是做起来比较麻烦；第二个原因是， 没人相信日程规划是可行的。

P157. Evidence-Based Scheduling

基于已知的历史记录（足够多的预期/实际比对数据），使用Monte Carlo simulation对任务的完成时间做出预测。
PS. 目前（我所知的）唯一实现EBS的管理软件就是Joel的FogBugz，你可以注册FogBugz的试用帐号并将其切换到2用户以下的免费模式。

P177. 你的编程语言做得到吗

很意外，我的编程语言做得到，事实上，即使是Java也能在某种意义上（痛苦的仿函数API）实现MapReduce。对于Groovy而言，闭包几乎可以满足你的一切。
PS. 当看到182页的时候，Joel指出，Java允许使用functor，当然，他也同意说着很痛苦。

P19*. 书写规范与匈牙利命名法

我并不完全赞同Joel的说法。Joel的目标很明确，无论是否使用匈牙利命名法，对于一个指定的实例而言，不应该对其进行语法上正确但语义上错误的操作。但在实践中，Joel的办法是更多的依靠人，让人眼睛一看到变量名就会意识到某些操作是允许的而另一些则要被禁止，但无法防止编译器放过人的疏漏；而大多数OO语言的方法则是从语法（确切的说是语句上下文）上把无语义的操作定为错误，但无法强迫人去做此类设计。在现实情况下，多数的Java程序员（尤其是OO新手）都不能做出正确的OO设计来防止非法的语义操作，但很不幸的是，让他们去使用匈牙利命名法的后果将一样的糟糕（因为他们将无法正确使用命名策略）。事实上我认为在如今强测试的编程风潮下，两种做法的带来的唯一显著区别将是OO语言（比如Java）将被迫对程序做最细致的切割。这在一定程度上会导致设计难度的提高，但我认为对后续的维护而言，细致的OO设计将胜过Joel的推荐方法。

P210. 本质上，软件的复制成本为0

这意味着如果软件的销量大，质量的改进几乎不会造成单位成本的增加，但却会创造出远远超出其开销的价值。

P221. 仿生学办公室

你的办公室不会和Fog Creek的一样好。但是有几点是可以做到的：许多许多的电源接口（而且和电脑桌齐高）；许多各式各样的数据线桥架；预算内能买到的最舒适的椅子。
目前我的期望是：两个巨大的接线板、高速的无线AP、两块白板（挂在我身后的玻璃墙上，这样老板就再没法透过玻璃看到我在睡觉了）、一个靠垫。（老板，可以派一个按摩师吗）

P226. 他山之石

对你最重要、最关键的部分，一定要使用更原始的工具。这也是我的习惯之一，但是要小心，注意只有“最重要”的部分才适合这么做，否则，你会发明一大堆的非标准轮子。（我的军火库已经超过米其林了）

P241. 一次性支付

当客户遇到一个技术问题的时候，合理的做法让开发团队一次性解决它，而不是让技术支持团队一遍又一遍的去处理。

P280. SLA

最大的问题是缺乏制定标准必须的统计资料。另外，对于服务稳定性而言，无法避免黑天鹅难题（Nassim Taleb），即小概率事件。对此，应该学习丰田的五个为什么。

Others

关于软件定价，这是一个我即将考虑的问题，我喜欢开源，但我需要钱:(