読書：ソフトウェア随想録（More Joel on Software）

別名 More Joel on Software（Joel谈软件）。読書メモとして、練筆。

きっかけ

最初にこの本を知ったのは、Limboy - 『ソフトウェア随想録』の短いメモというブログ記事だった。
阮一峰のブログにも『Joel談ソフトウェア』が出版されたという記事があり、コメント欄の評判も良さそうだった。

最初は軽く中身を眺めるつもりだったのに、内容が面白くてそのまま読み進めてしまった。著者の文章はユーモラスで、何か所かでは思わず笑ってしまった（たとえば第25章 Micro-ISV で、古巣の Microsoft の高慢さを皮肉っているあたり）。
阮一峰の翻訳も自然で読みやすく、英語の小ネタを理解しやすいように脚注もたくさん付いていた。

『More Joel on Software』（Joel談ソフトウェア／ソフトウェア随想録）は専門技術書というよりエッセイ集に近い。Joel の個人ブログ Joel on Software の精選記事をまとめた本だ。
著者は経歴も豊かで、Microsoft では Excel 開発チームのプログラムマネージャーを務めていた（Microsoft のプログラムマネージャーは、チーム内で最も技術力が高く、なおかつ人を惹きつける力のある人だという）。
途中で Wikipedia を見たら、Stack Overflow も彼の創業だった。Joel ありがとう、Ctrl C と Ctrl V を使えるようにしてくれて。
本全体のまとまりはそこまで強くない。ブログ記事の集成なので、同じ話が繰り返されることもあるが、気になるほどではない。

参考になった本

この本にはいくつか本や人名が出てくるので、メモして読書リストに入れておく。~~いつか~~

人件（Peopleware）、有名だがまだ読んでいない
人月神話、さらに有名（これは読んだ: 読書：人月神話
MIT 6.001 Structure and Interpretation of Computer Programs、1996 年版。Resources に HTML 版全文があり、動画講義も付いている

では、メモ本編へ。

第 1 部人員管理

1 初めての Bi11G レビュー

ここでいう BillG レビュー は、ビル・ゲイツによるレビューのこと。
著者は 1992 年、Microsoft の Excel チームでプログラムマネージャーを務め、ある重要機能を担当していた。
レビュー前、著者は提出資料に抜けがないか確認していたが、Excel と Basic の日付・時刻関数の挙動が一致しないことに気づく。Excel が当時の Lotus 形式との互換性を保つ必要があったためだ。
翌日のレビュー会では、前日に提出した 500 ページの資料の隅々まで、ビル・ゲイツがコメントを書き込んでいた。
質問はだんだん難しく、細かくなり、最後には日付と時刻関数のごく細かい点にまで及んだ。著者が答えると、そこで質問は終わった。
著者は、ビル・ゲイツをごまかそうとしない方がいいと感想を述べる。彼は本物のプログラマで、技術理解が驚くほど深いからだ。
ついでに Lotus も少し皮肉る。プログラミングを理解していない人がソフトウェア会社を運営するのは、サーフィンを知らない人が無理やり波に乗ろうとするようなものだ。

2 優秀なプログラマを探す

著者は、最高のプログラマは求人市場には出てこないと考えている。
優秀すぎるので、大学を卒業する前から教授の推薦が付いているからだ。
そういう人が転職するとしても、起業か次の仕事へ移るかのどちらかで、働く先は自分で選べる。履歴書をばらまく必要はない。

その前提で、著者は次のような方法を勧めている。

外に出て、専門的な技術コミュニティや技術カンファレンスで人材を探す。
インターン。著者の会社では、卒業まであと 1〜2 年の大学生にさまざまな経路で声をかけ、優れたインターン機会を提供して、早いうちから人材を引き寄せている。
コミュニティを作る。著者自身のブログは読者が 100 万人にもなるが、これは再現が難しい。

また、社員紹介には注意が必要だとも述べている。競業避止義務の問題もあるし、紹介ボーナス目当てで無責任に人を勧めるケースもあるからだ。

3 優秀なプログラマを惹きつける実践ガイド

トップクラスのプログラマが仕事に困っていないなら、その人たちにとって魅力的な職場にすることが重要になる。
著者はいくつか提案している。

個室
生産性が上がり、評価されていると感じやすい。
職場環境
会社の中は清潔で明るく、外も設備が整っていて気持ちがいい。
おもちゃ
ここでいうのはプログラマの仕事道具だ。大きなモニター、大きな机、技術書を自由に買えること。
プログラマの社交生活
会社がプログラマをどう扱うか。歯車扱いか、中心人物として扱うか。
頭が良くて感じのいい同僚。
自主性。賢い人に仕事を任せ、その専門性を尊重すること。
政治を持ち込まない
悪質な社内政治は避ける。多くの人がプログラミングを選ぶのは、公平で秩序のある場所で時間を使いたいからだ。コードは動くか動かないか、そこがはっきりしている。
何をしているのか
プログラマは、面白くてかっこよく見える仕事を好む。
Oracle では、一流の社員に自分が入りたいプロジェクトを選ばせていた。
社内ツールや重要でない新規プログラムなどで、興味のある新技術を自由に使わせるのもありだ。
自分はこの会社に共感できるか
仕事の意味、オープンソース運動、フリーソフトウェア運動、非営利の社会活動、前向きなブランドイメージなどは、会社への共感を高められる。
プログラマがそれほど気にしないこと
上のような要素に比べると、プログラマは金銭にはそれほど執着しない、と著者は述べる。
報酬がある程度まともなら、給与の多寡はそれほど重要ではない。

かなり理想化された職場ではあるが、その後 Joel は実際に Fog Creek Software を立ち上げ、いくつかを実践した。

4 3つの管理方法

会社では誰もがそれぞれの私的な目標を持っている。それをどう統合して、みんなが同じ方向を向くようにするか。
著者は次の 3 章で、一般的な 3 つの管理スタイルとその長所・短所を論じる。

5 軍隊式管理

よくある管理手法だが、欠点もはっきりしている。

頭のいい人、あるいは大半の人は、命令されっぱなしを好まない。
軍隊式の管理は細かい調整が難しい。
軍隊なら、司令官が号令をかければ兵士が一斉に三十周走ればいい。
でも会社では、各人で職務も仕事も違うので、マネージャーが全員を細かく見るだけの時間も気力もない。
その結果、hit and run みたいな場当たり的な管理になりがちだ。
ハイテク企業では、実際に手を動かしている人の方が上司より情報を持っている。だから、その人たちこそ決定を下すのに向いている。
著者は Microsoft にいた頃、Mike Maples が技術問題には口を出さず、技術案の決定権をプログラマに渡していたと書いている。

6 金銭インセンティブ方式

要するに、KPI を決めて金銭的な報酬を与えるやり方だ。

欠点は、プログラマの いいコードを書きたい。なぜなら良い仕事をしたいからだ という内発的動機を、いいコードを書きたい。なぜならお金が好きでボーナスが欲しいからだ という外発的動機に変えてしまうことだ。これは実際には、優れた仕事をしたい気持ちを弱める。ボーナスを止めれば、コード品質への関心もなくなる。

もう一つの問題は、プログラマやあらゆる社員が制度をゲーム化し、抜け穴や欠陥を探し始めることだ。最後には、ルールを作る側とプログラマの猫と鼠のゲームになる。

著者が考える 金銭インセンティブ方式 の最大の問題は、これは管理ではなく、管理の放棄だということだ。うまく設計された責任逃れの方法にすぎない。
それは、経営側が人をより良い仕事へ導く方法をまったく分かっていないことを示している。だから社員が制度の枠内で自力で何とかするしかない。
たとえばコードを書くなら、正しいやり方はお金をばらまくことではなく、社員を訓練してプログラミング能力を上げることだ。

7 同一化

同一化の目的は、内発的な動機を生み出すことだ。

一方で、社員の会社への共感を高める。

会社に遠大で高尚な目標があれば、社員は自分の仕事を誇れる。
著者が好む方法の一つは、みんなで食事をすること。会社が家族のように感じられ、社員が会社を好きになるという考えだ。

emmm、ちょっと評価しづらい。

もう一方で、会社の意思決定の背景を社員に理解してもらうために、必要な情報も与えなければならない。そうすれば、みんなで正しい方向へ進める。

第 2 部未来のプログラマへの助言

8 Java だけ教える危険

关于这章的标题，阮一峰老师在博客《Joel谈软件》出版了里特别提到，摘录下来:

中文版的书名叫《软件随想录》，还有一个副标题《程序员部落酋长 Joel谈软件》。

不要问我为什么起这个名字，因为我也不知道。这是出版方的决定，可能是希望多争取一些非专业读者吧。

此外，由于出版方有最终的决定权，所以一些句子的译法和某些篇目的名称都做了改动，我对此也无能为力。比如，《Java语言学校的危险性》一文，现在的名字是《学校只教Java的危险性》，智者见智吧。

冒頭だけ見ると、また 最近の若者はダメだ、苦労に耐えられない、昔の自分たちは... というお決まりの話かと思う（笑
でも実際には、著者が言いたいのは、Java は難しさが足りず、優秀な情報系学生を選別する手段にはならないということだ。

著者は、自分の考えはラテン語支持者と変わらないと言う。ラテン語は思考を鍛え、記憶を鍛える。ラテン語の構文を分析することは思考力を鍛える最高の練習であり、知性への本当の挑戦で、論理力をよく育てる。
著者は、ポインタと再帰はコンピュータ科学におけるラテン語のようなものだと考えている。

著者も、現代のソフトウェア開発では、ほとんどの場面でポインタや関数型プログラミングは必要ないと認めている。

但如果不懂指针，一行 Linux 代码都看不懂，不懂函数式编程，就无法创造出 Google 的 MapReduce
更重要的是，指针和递归的真正价值是你在学习他们的过程中所得到的思维深度，以及你因为害怕在这些课程中被题材所产生的心理抗压能力
指针和递归要求一定水平的推理能力、抽象思考能力，以及最重要的，在若干个不同的抽象层次上同时审视同一个问题的能力
因此，是否真正理解指针和递归与是否是一个优秀程序员直接相关

著者が挙げているトピックは次のとおり：

指针（pointer）
递归（recursion）
数据结构
不动点定理（fitxed pointer theory）
函数式编程（functional programming）
MIT 6.001 Structure and Interpretation of Computer Programs

9 Yale での講演

和上一篇内容有点类似，都是说课程内容足够难才能筛选出真正适合学计算机的学生

作者试听了一节 动态逻辑 课程就知道自己不是馆理论的料

より高品質なコードをどう作るかについて、著者はソフトウェア界を 技術派（geek） と 実務派（suits） に分けている。
技術派（geek） は、自動化技術でソフトウェア品質を上げようとする人たちで、たとえば 単体テスト（unit testing）、 テスト駆動開発（test-driven develoment）、 自動テスト（automated testing） などだ。
実務派（suits） は品質にはあまりこだわらず、売れればそれでいい、という立場だ。

著者は 実務派（suits） の方により賛成していて、理由を 2 つ挙げている。

コード中の bug を潰すのは、限界効用が下がっていく作業だ。
ある程度の品質に達し、実用上の問題を解決できるなら、ユーザーが買ってくれるだけで十分だ。
技術派（geek） の コード品質 の定義は狭すぎる。自動化技術はコード内の問題を保証できるが、
UI が美しいか、インタラクションが妥当かといった自動テストできない部分は コード品質 の外に追いやられてしまう。
その点 実務派（suits） の定義はずっと広く、そうした要素もすべて「売れるかどうか」に関わる。

世界のプログラマの 80% は社内向けソフトウェアを作る内部プログラマだが、著者はこの仕事に注意しろと言う。
内部プログラマは先端技術を選べないことが多く、作るものも 動けばよい というレベルで済まされがちで、外販製品のように磨き込みや改善を続けるわけではない。
それに、内部プログラマは会社にとってコストであり、会社は利益を生む人の方を好む。
技術は古くなり、好みは悪くなり、交渉力もない。内部プログラマはとても受け身な立場だ。

著者は、分かりやすい技術記事を書けるかどうかで、その人が口ごもるプログラマなのか、それともリーダーなのかが決まると考えている。だから、文章力は非常に重要だ。

10 情報系学生への助言

毕业前练好写作
毕业前学好 C 语言
毕业前学好微观经济学
不要因为枯燥就不选修非计算机专业的课程
选修有大量编程实践的课程
别担心所有工作都被印度人抢走
找一份好的暑假实习工作

第 3 部設計の役割

11 フォントスムージング、アンチエイリアス、サブピクセルレンダリング

苹果的字体渲染方式更倾向终于字体的原始设计，即使有损清晰度也在所不惜
微软则倾向保证可读性，即使背离字体的原始设计

如果你问人们喜欢什么样的风格和设计，除非受过专业训练，否则他们一般会选择自己最熟悉的品种

12 1 ピクセルでも争う

做优秀产品需要「强迫症」一样的精神

为了发现可以改进的地方，你必须有一个思维定势，始终如一地用批判地眼光看世界
当你改正了一个又一个这样的小细节后，当你磨光、定型、擦亮、修饰你的产品的每一个小边角后，就会有神奇的事情发生。厘米变成分米，分米变成米，米变成了千米。你最后拿出来的是一件真正优秀的产品。它第一眼就让人觉得震撼，出类拔萃，工作起来完全符合直觉。就算 100 万个用户中有一个用户某天突然要用到一个他 100 万次使用中才会用到一次的罕见功能，他发现了这个功能不仅能用，而且还很美：在你的软件中，即使是看门人的小屋都铺着大理石地板，配有实心的橡木门和桃花心木的壁板。
就是在这个时候，你意识到这是一个优秀软件。*

13 大構想の罠

这篇是作者对 Scott Resenberg 《梦断代码 (Dreaming in Code)》一书的评论

人们往往高估自己清晰判断事物的能力，总是觉得自己看到了全部，即使事实并非如此
在软件开发中，这种错觉会导致你感觉自己已经在头脑中形成了整体设计，每一步都清晰无比，这时立刻开始着手工作就会掉入两个陷阱：

对自己的设想过于自信
认为自己不需要详细的说明书，直接开始写代码就行

生活中也经常有这样的情况，例如写博客，感觉脑海中想法很清晰，但实际坐下来打字时不是抓不住头绪、无从下笔，要不然就是思路混乱、废话连篇
在做产品设计之前就开始雇佣程序员
世界上只有一件事比你自己设计软件更困难，那就是一个团队一起设计软件

《人月神话》贵族专制、民主政治和系统设计(Aristocracy, Democracy, and System Design) 一节也讨论了类似主题：为了保持概念完整性需要在设计阶段实行「贵族专制统治」，一群人开会做决定只会拖累进度、降低品质

14 ユーザーに選択肢を与えすぎない

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

想到《天真的人类学家：小泥屋笔记》结尾主人公从非洲原始部落回到英国现代社会时的感受，选择过于丰富，就像被海量嘈杂信息淹没

作者讨论了如何将 Windows 中 15 种关闭计算机的方法精简成一种，思考过程非常有趣，建议看原文
微软和大部分开源软件都有这样的问题，菜单设计的大而全，往往过于繁琐

但总感觉苹果的理念是规定用户「你应该这样用」，如果自己的使用习惯恰好和苹果规则一致时很舒服，当你一旦想稍微偏离苹果的使用规则，那就抱歉了

15 使いやすさだけでは足りない

社会化界面工程学 (social interface engineering)
社会上存在各种各样的人，想占便宜的、搞诈骗的、为非作歹的，社会化软件里也存在这类问题
例如，如何应该在论坛里发广告的人？
一种办法是弹出错误信息，禁止发广告
另一种办法是假装系统接收了用户发送的广告，他觉得目的达成，就会转到其他地方继续发广告

16 ソフトウェアでコミュニティを作る

软件项目同建筑项目一样，设计规划非常重要，它能够决定在线社区的成败和它的类型。如果你让某个功能很容易操作，人们就愿意使用它。如果你让某个功能很难操作，人们就会避免使用它。通过这种方式，你能够暗中鼓励人们按照预想的方式表现，这决定了一个社区的特性和品质。
软件实现上的小细节会导致在线社区发展、运作、用户体验上的大差异。

最近看到一个视频，提到动画和真人电影的区别，金敏说 动画是从零开始，不带着意图就无法进行的创作，所以动画的每一帧都是经过设计的
这似乎和软件也有点类似，同样是从零开始的作品，作品中的每一个细节都反映了创作者的意图
想要做出什么样的软件？
想要传达什么理念？
希望用户如何使用这个软件？
这些都需要创作者自己心中有答案

这章内容里 Joel 对搭建高质量社区的一些思考值得一看

第 4 部大規模プロジェクトの管理

17 火星人のヘッドホン

本章讨论 IE 7 升级 IE 8 过程中为了符合 Web 标准，理想主义阵营 (严格遵守新标准) 和 实用主义阵营 (兼容旧标准) 之间爆发的口水大战
最终结果是 IE 8 默认使用新标准，但同时提供 兼容性视图

18 Microsoft Office のファイル形式が複雑な理由（と対策）

稍微一窥 Excel、Word 的复杂性

回顾整个历史，程序员无时无刻不想做出正确的事情，但是有时候你不得不向现实屈服。

如果不得以要和 Office 打交道，作者给了两个对策：

让 Office 为你干脏活
用一种更简单的格式生成文件
生成 CSV 格式文件给 Excel 处理，HTML/RTF 格式给 Word 处理
而非想办法生成 Office 文件交给 Office 处理

19 もうけたいなら、汚れを恐れるな

解决轻而易举的事情是拿不到钱的

但在日本怎么经常感觉 这玩意儿也能卖钱？、这玩意儿也有人买？（

编写一个设计优雅、易于使用的应用程序，同解决「麻烦事」有相仿的效果。虽然看到成品的时候，你会觉得不难做，但实际上是很难的。就好比你在看精彩的芭蕾舞演出，你觉得演员跳起来很轻松，实际上换了你就困难无比。Jason 和他的 37signals 致力于做出优秀的设计，他们得到了回报。优秀的设计似乎是最容易复制的东西，但是做起来却又不是那么容易，你看看微软试图效仿 iPod 的例子，就会明白这一点。做出优秀的设计本身就是一件「麻烦事」，实际上能够提供牢固得令人震惊的竞争优势。

第 5 部プログラミングの助言

20 エビデンスベースのスケジュール管理

如果日程规划是以「天」为单位，甚至以「周」为单位，我就认定它是没用的。你必须将日程规划先分解成一些非常小的任务，这些人物能够在以「小时」为单位的时间段中完成。不能有任何人物所需的时间超过 16 小时。

保留好工作时间记录单。让你用在每项任务上的时间长度留下可以追踪的痕迹。以后，你就可以回过头来参考这些数据，估计一下新的任务相对需要的时间。

只有第一线的程序员才能提出完成日期的估计值
一发现错误就立即修正，将用时算入原始人物的用时之中
防止管理层向程序员施加压力，要求加快开发速度

有效的日程规划有许多很大的好处，其中之一就是你会被迫删去一些功能
删掉容易做的，或是有趣的功能，砍到不能再砍的地步，只保留能够把产品变成真正优秀产品的重要功能

21 戦略上の問題に関するレター VI

有一些程序员将大量经理投入优化工作，要将程序变得更紧凑、更快速。某一天，他们醒来后发现，这种努力基本上是白忙一场。
从长远的观点来看，那些不关心效率、不关心程序是否臃肿、一个劲往软件中加入高级功能的程序员最终将拥有更好的产品。

22 そのプログラミング言語でできるか

这章讨论 函数式编程 (functional programming)，下面是一些摘抄：

如果你不懂函数式编程，你就无法创造出 MapReduce，正式这种算法使得 Google 的可拓展性（scalable）达到如此巨大的规模。术语 Map（映射） 和 Reduce（化简） 分别来自于 Lisp 语言和函数式编程。回想起来，在类似 6.001 这样的编程课程中，都提到纯粹的函数式编程没有副作用，因此可以直接用于并行计算。任何人只要还记得这些内容，那么 MapReduce 对他来说就是显而易见的。发明 MapReduce 的公司是谷歌，而不是微软，这个简单的事实说出了原因，为什么微软至今还在追赶，还在试图提供最基本的搜索服务，而谷歌已经转向了下一个阶段，开发 Skynet，我的意思是，开发世界上只打的并行式超级计算机。我觉得，微软并没有完全明白在这一波竞争中它落后了多远。
好的，我希望到了这个时候，你已经深信不疑了。你确信，那些具备了 第一类函数 功能的编程语言，能够让你更容易地完成进一步抽象代码的任务。这意味着你的代码体积更小、更紧凑、更容易重复利用、更方便拓展。谷歌的许多应用程序都使用了 MapReduce 技术，所以一旦有人对底层的并行计算程序进行优化或消除 bug，那么所有这些应用程序都会受益。
说到这里，我有点动感情了，忍不住想站起来说，最优生产效率的编程环境是那些允许你在 不同层次上进行抽象 的编程环境。

看得出来作者非常推崇这种编程方法/思考模式，最近学习 JavaScript 和 Python 的过程中也接触到了一些函数式编程内容，似乎能理解原理，但如何在实际中运用函数式编程方法，特别是 如何设计程序 以满足函数式编程思想，这方面还完全不了解，也许以后可以找 Lisp/Haskell 这类纯函数式编程相关的书籍来看看

23 間違ったコードを見えやすくする

作者讲述了程序员的 4 种境界：

你分不清什么是干净的代码，什么是不干净的代码。
你对干净的代码有一个肤浅的认识，主要看它们是不是符合代码书写规范。
你开始能找出那些很隐秘的不干净代码，在干干净净的表面之下发现蛛丝马迹。但是，发现和修正不干净代码要花去你很长的时间，把你折磨得够呛。
你精心构建代码，发挥洞察力，将它们写得清晰易懂，不容易出错。

作者认为做好的做法是：
寻找一种代码的书写规范，让错误的代码变得更容易被看出。
让代码中的相关信息在显示屏上集中在一起，使你能够当场发现和改正某些种类的错误

作者还批评了异常处理，认为这不是一个好工具

这部分没太理解，作者给出了一些推荐阅读材料 Making Wrong Code Look Wrong 这篇博客最后 More Reading 部分
Raymond Chen’s essay: Cleaner, more elegant, and harder to recognize

第 6 部ソフトウェア会社を立ち上げる

24 『Eric Sink on the Business of Software』への序文

有趣的小故事，有一项不断成长的生意会让人非常有成就感（~~顺便还吐槽了一波他遇到的垃圾人~~

25 『Micro-ISV: From Vision to Reality』への序文

开头大力吐槽微软高高在上的姿态，语言太幽默，忍不住笑出声

作者对想创业的人给出三条建议：

如果你说不清楚你的软件解决了什么棘手的问题，就不要去开软件公司。
不要独自一人创办公司。
一开始不要抱太高期望。

作者描述创业的乐趣：

总结一下，我所认为的创办软件公司的真正乐趣就是，创造一些东西，自己参与整个过程，悉心培育，不间断地劳作，不断地投入，看着它成长，看着自己一步步的到报偿。这是世界上最带劲的旅程，无论如何，我都不想错过它。

26 高音を出す

软件的复制成本为零，如果销售量很大，高价雇佣程序员的成本可以分摊到销量上，单位软件成本并不会显著上升

优秀程序员的生产效率比普通程序员高 5 到 10 倍，那么是否可以用 5 个平庸程序员来代替 1 个优秀程序员呢？
答案是不能，不仅因为布鲁克斯法则（Brooks‘ Law）：向一个已经延误的软件项目增加人手，只会使它更加延误

Brooks 就是《人月神话》（The Mythical Man-Month）的作者
而且平庸的程序员无论工作多长时间，他们做出来的东西也无法像优秀程序员一样好
一流的歌唱演员不管在什么时候，都可以很轻松地唱出高音，而平庸的歌唱演员就是永远做不到这一点

第 7 部ソフトウェア会社の経営

27 バイオニックなオフィス

作者开公司，他是一个真正的程序员，并且按照他的理想布置了适合程序员工作的办公空间，最终成本是人均 700$/月，非常舍得花钱
去 wiki 上看了看公司的后续，疫情期间被收购了，详细情况不太了解，但还是叹息，理想主义公司生存真是太困难了

28 他山の石

将 FogBugz 许可证变为公开源代码的理由

29 単純さ

简化 并不是 简陋
产品易于理解使用、外观简洁明快，都是加分项
但不能把 简化 理解为 不提供大量功能 或者 只提供一种功能，并把这种功能完美实现

30 もんで、こすって

代码重构（refactoring）的原则：

不添加任何新功能
无论何时向源码库提交代码，都要保证程序依然能够完善地运行
制作一些合乎逻辑的变换（logical transformation），几乎都是机械性的，而且能够立刻确定不会改变代码行为

作者认为这样的重构有许多优点：

耗时大大少于一次彻底的重写
没有引入任何新错误
在任何时间，如果有必要，都可以停下来，把程序交出去
工作进度是完全可以预测的
重构所花费的时间可以为之后的新功能开发节省时间

31 ベータテストを組織する 12 の極意

开放式的 Beta 测试是没用的
要想找到那些能够向你反馈意见的测试者，最好的方法是诉诸他们 言行一致 的心理。你需要让他们自己承诺会向你发送反馈意见，或者更好的方法是，让他们自己申请参加 Beta 测试。
不要妄想一次完整的 Beta 测试的所有步骤能够在少于 8~10 周的时间内完成
不要妄想在测试中发布新的软件版本的频率能快于每两周一次
一次 Beta 测试中计划发布的软件版本不要少于 4 个
如果在测试过程中你为软件添加了一个功能，那么哪怕这个功能非常微小，整个 8 个星期的测试也要回到起点
即使你有一个申请参加 Beta 测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见
我们制定了一条政策，所有向我们提交反馈意见的测试者都将免费获赠一份正版软件，不管反馈意见是正面还是负面
你需要的严肃测试者（即那些会把反馈意见写成 3 页纸发送给你的人）的最小数量大约是 100 人左右
根据第 7 条，即使你有一个申请参加 Beta 测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见。那么，假定你有一个质量控制部门，里面一共有 3 个测试管理人员，这就意味着你必须批准 1500 份参加 Beta 测试的申请表，因为这样才能产生 300 个严肃测试者。
大多数 Beta 测试的参与者只是在第一次拿到这个程序的时候才会去试用一下，然后就丧失了兴趣。你需要错开不同版本的测试对象，将所有 Beta 测试参与者分成四组，每次发布一个新版本的时候，就把一个新的组加入测试，这样就能保证每个版本都有第一次使用这个程序的测试者。
不要混淆 技术 Beta 和 市场 Beta。上面这些都是针对 技术 Beta，它的目标是发现软件中的错误和得到及时的用户反馈意见。

32 よい顧客サービスを築く 7 つのステップ

每件事都有两种做法
一种是简单、快速的解决当前问题
另一种是把探究问题产生的原因，一劳永逸地解决这个问题。长此以往，所有常见的和容易的问题都被解决了，留下来的都是一些非常罕见和奇特的问题。这样可以节省常规性技术支持的成本。
当然，后一种办法对客服人员的要求更高，需要技术支持团队可以与开发团队直接沟通。
建议吹掉灰尘
Raymond Chen 讲过一个小故事。有一次，客户打电话来抱怨键盘失灵，结果不出所料，原因是键盘没插好。但是如果你直接问客户键盘有没有插好，他们会觉得受到了侮辱，怒气冲冲地回答：“它当然插好了！难道我看上去像一个笨蛋吗？”而实际上，他们并没有检查过接口。
“你可以换一种说法，” Raymond Chen 建议改成这样说：“别着急，有时候键盘接口会有灰尘，导致接触不良。你能不能拔掉键盘插头，吹掉上面的灰尘，然后再把它插回去？”
“然后，客户爬到桌子底下，发现自己忘了插好插头（或者把插头插入错误的接口）。他们把灰尘吹掉，插入插头，回复你说：‘嗯，很好，问题解决了，谢谢。’”
很多时候，我们要求客户去检查某样东西，都可以这样表达。不是直接要求他们去检查某个设置，而是告诉他们先改变这个设置，然后再改回去，目的是 “确保这个设置被保存进了软件”。
让客户迷上你
客户遇到问题，你帮他解决了，并且是以漂亮的、超过客户预期的方式解决这个问题后，客户实际上变得比没有问题时还要满意，很容易成为你的重视客户，还会向别人推荐。
承受责备
坦诚地承认自己的错误
学会说软话
和上条一样，承认自己的过失，并解决问题，防止他人对你火冒三丈
学会做木偶
还是和上面类似，对事不对人，不要觉得别人的批评是对自己的人身攻击
贪婪让你一无所获
作者的公司 Fog Creek 的客服从来没有遇到过愤怒的顾客，他们公司的退款政策是 “如果你是用我们的产品，不觉得异常欣喜，我们就不要你的钱”
这样顾客就不会有后顾之忧，大不了退钱。
作者公司设置这样异常慷慨的退款政策，6 年时间中，因为接受顾客退货儿导致的成本只占总成本的 2%。
如果把退款政策制定的很严格和苛刻，反而有可能会惹火一些顾客，损失潜在客源。

附赠建议：为客服人员提供职业发展道路
作者安排了非常称职的人与客户交谈，Fog Creek 的销售人员对软件开发流程有丰富的经验
通过改进软件，他们已经把常见问题都消灭了，技术支持工作实际上变成了处理疑难杂症，需要经常对程序进行调试和除错
作者还为客户服务人员提供一条明确的职业发展道路，公司出钱让他们攻读哥伦比亚大学技术管理的硕士学位
这让作者招聘到有抱负、聪明的技术人才，尽管付出了超额成本，但也创造出了比一般水平多得多的价值

第 8 部ソフトウェアを公開する

33 リリース日を選ぶ

制定软件开发周期的基本规则：

确定发布日期，这个日期可以根据客观情况也可以根据主观情况进行选择
列出软件要实现的功能，然后按照优先顺序排序
每当你落后于预订进程时，就把排在最后的功能砍掉

挑选软件发布日期的规则：

经常发布稍作改进的版本。适合顾客人数较少的项目。
每 12 个月到 18 个月发布一次。适合上架销售的商业软件和桌面应用程序，拥有大型开发团队和成千上万名顾客。
每 3 到 5 年发布一次。常见于超级庞大的软件系统和平台。

不要因为答应过一个顾客而开发某个功能，应该始终面向整个市场开发软件
不要因为某些事情不得不做，你就去做。不得不做不是一个足够好的理由，要想清楚什么是眼下最重要的、必须马上做好的事情

确定软件开发中各种任务的优先顺序的步骤：

召集尽量不同观点/视角的团队：程序员、设计师、客服人员、销售人员、管理人员、文档作者、测试员，甚至包括客户。每个人都提出一些想要实现的功能，最后得到一份包含 50 项重大功能的清单
审查这些功能，每个人进行表决，简单地表示 “赞成” 或是 “反对”，筛选过后，剩下 36 个功能
为每个功能设定一个成本，用 1 到 10 表示，这一步只是区分小型任务、中型任务、大型任务，不需要精确计算实际开发所需的时间
把 36 个功能和它们的成本做成一张菜单，每个人有 50 美元用来点菜。可以买半个功能，也可以同样功能买两个
汇总每个功能的销售额，用 销售额 除以 成本，找出最受欢迎的功能
最后可以根据功能之间的联系做一些调整
优先顺序确定之后，按照清单从上往下进行开发，直到开发阶段结束，没有时间完成的功能就直接舍弃，或是留到下个版本开发

さいごに

看一遍，复读一遍，特别是在学习了 Python 和 JavaScript 里函数式编程概念之后，对一些章节理解更加深刻了
不错，有收获