《软件随想录》读书笔记

《软件随想录》读书笔记
第一部分 人员管理
1 我的第一次BillG审查
安排给我的职责是为Excel宏语言找到一个解决方案。
所谓解决方案就是要让它与Basic编程语言联系起来。
我设法在Basic里加上了4样好东西：变型、后期绑定、从UNIX的shell语言csh中借鉴的For Each结构，以及从Pascal语言中借鉴的With结构。
不懂编程的人管理软件公司，就好像不懂冲浪的人硬要去冲浪。
2 寻找优秀的程序员
优秀的程序员都在哪里
就同所有行业中最好的人才一样，那些优秀的程序员是不会出现在招聘市场上的。
我能得到他们吗
我有3个实现这个目的的基本方法。
（1） 走出去。
（2） 实习生。
（3） 建立自己的社区。这一条有难度。
走出去，伙计
你可以浏览“Joel谈软件”网站上的求职讨论区，将搜索范围缩小到那些阅读我的网站的聪明人。
你还可以去那些真正有趣的技术会议上寻找合适的人。
你要关心正流行的热门新技术。
不要在大型的求职论坛发布没有针对性的招聘广告。
实习生
当他们还在学校的时候就出手。
一个真正优秀的程序员往往在10岁的时候就开始编程。
有些实习生确实是优秀程序员，但是我们愿意让他们离开，还有一些实习生可能在其他地方会成为优秀程序员。
实习生制度创造了输送优秀人才的管道，但是这根管道比较长，而且一路上的损耗很大。
建立社区
创造一个大型的网络社区，让观点相近的优秀软件开发者以某种形式聚集在你的公司的周围。
员工推荐：小心陷阱
员工推荐是最不可靠的招聘新人的方法之一。
一个无法回避的巨大风险，就是竞业限制合同。
如果你不能保证应聘者百分之百被接受，那么当你要求你的雇员推荐人选时，他们甚至都会考虑向你说出他们真正的朋友。
如果负责招聘的人事经理懂一点经济学，决定为每一个有效的推荐提供奖金，麻烦就来了。
3 寻找优秀的程序员之实战指南
私人办公室
如果你要让程序员高效工作，你就必须给予他们安静和宽敞的工作环境，比如说私人办公室。
私人办公室意味着更高的地位。
小隔间和其他共享的空间会带来某些尴尬和不便。
如果提供私人办公室，程序员就有更大的可能接受你的工作邀请。
工作环境
当一个应聘者在面试的那一天来到你的公司，他们肯定想多看看里面的人是怎么工作的，并且设想他们自己在这个环境中工作会怎样。
玩具
没有理由不给你的程序员配备顶级电脑，不给他们设置上限，都会带来很明显的效率上的提高，它们是招募优秀程序员的杀手锏。
程序员的社交生活
λ 程序员在组织中如何被对待
如果你不尊重程序员，你就不会得到优秀的程序员。
λ 谁是他们的同事
不收怪人
λ 独立自主
如果你要雇佣聪明人，你就必须让他们在工作中发挥技能。
管理层可以提出建议，但是不能让他们的“建议”被视为命令。
λ 不搞政治
不搞恶性的政治。
没有什么比因为技术原因赢得一场由于政治原因本来要输掉的争论更让人心满意足了。
我干的是什么活
让程序员干有趣的活是吸引优秀程序员的最好方法之一。
另一类程序员喜欢干的活是开发一些非常简单或者非常流行的东西。
许多程序员也会关注他们服务的公司的社会价值。
- 让一流的新员工挑选他们自己的项目
- 使用非必要的热门技术
我能够认同公司吗
思考你的公司代表了这样的追求，这种追求是怎么形成的，又是怎么才能被别人感受到。
管理好你的公司的品牌不仅对营销很重要，对招聘新人也同样重要。
程序员不在乎的一件事
他们实际上不在乎钱，除非你在其他事情上搞砸了。
并不意味着你可以向他们支付低工资，因为程序员对公平公正是在乎的。
4 三种管理方法
如何使得人们去做你要他们做的事，这里有三个你或许会采用的一般性方法：
（1） 军事化管理法
（2） 经济利益驱动法
（3） 认同法
5 军事化管理法
有三个缺点。
首先，人们并不喜欢被这样管，尤其是那些对智商很自负的程序员。
没有足够的时间用在微观管理上，原因很简单，因为经理的人数不够。
第三个缺点是，在高科技公司中，负责干活的个人总是比“领导者”有更多的信息，所以他们其实是做决策的最佳人选。
软件开发团队中的优秀程序员可以去任何他们想去的地方工作。在这种前提下，如果被人当成士兵一样对待，他们会感到相当扫兴，因此你要是这样做，最后就只能成为“光杆司令”了。
6 经济利益驱动法
“经济利益驱动发”假设每个人的行为动机都是金钱，让人们听命于你的最好方法就是给他们物质奖励或者物质惩罚，以此创造行为动机。
这种方法的一个重大问题是，它将内部激励变为了外部激励。
内部激励比外部激励强得多。人们会为那些他们真正想做的事格外努力地工作。
另一个大问题是，人们有追求局部利益最大化的倾向。
如果你使用经济利益驱动法，你就是在鼓励程序员与制度博弈。
不管你用什么标准来评估他们的表现，他们都会找到办法将评估值最大化，所以你永远也得不到你真正想要的结果。
7 认同法
这种管理方法的目标是，使得人们认同你希望达到的目标。
如果公司的目标确实在某种程度上是高尚的，或者至少在别人看起来是高尚的，那么肯定有助于人们产生认同感。
认同法要求你创造一个有凝聚力的、像胶水一样粘在一起的团队，就好像家庭一样。
认同法的第二部分则是向人们提供必要的信息，使得公司向正确的方向前进。
第二部分 写给未来程序员的建议
8 学校只教JAVA的危险性
Java不是一种非常难的编程语言，无法用来区分优秀程序员和普通程序员。
是否真正理解指针和递归与是否是一个优秀程序员直接相关。
大学里只教Java语言，无法淘汰那些永远也成不了优秀程序员的学生，那已经是很糟糕的事情了。
9 在耶鲁大学的演讲
第一部分
计算机界可以分成技术派和务实派。
技术派想要把质量问题用软件自动处理。
务实派并不真地关心质量有没有问题。
务实派是获胜的一方，因为他们控制了公司的预算。
单元测试本身并不坏，当你运行完所有的单元测试，就可以机械式地“证明”一个程序是“正确的”。
所以软件的美观就被排斥在自动化QA过程之外。
为了机械方法证明程序符合某种规格，规格说明书本身就需要写得非常详尽。实际上，设计规格说明书是那个不得不因此定义清楚与程序无关的每一件事。
第二部分
为什么做一个内部程序员就糟透了？
第一点。 你永远无法用正确的方法做事。你总是被迫用最保险的方法做事。
第二点。 因为一旦你的程序可以用了，你就不得不停止开发。你做不出优秀的产品。
第三点。 如果你在专业的软件公司中编程，你的工作与公司的主营业务直接相关，是能够直接为公司带来收入的。
第三部分
能不能清晰地写出技术内容的文章决定了你是一个口齿不清的程序员还是一个领袖。
10 给计算机系学生的建议
（1） 毕业前练好写作。
Linux吸引来全世界一大批志愿者的真正原因是Linus Torvalds的表达能力。
团体中最有权势和影响力的程序员正式耐饿表达能力强的程序员。
（2） 毕业前学好C语言。
你至少需要花一个学期来了解机器原理，否则你永远不可能在高级语言的层次写出高效的代码。你也永远无法开发编译器和操作系统，而它们恰恰属于目前程序员能够得到的最佳工作之列。
（3） 毕业前学好微观经济学。
从经营一家公司的角度来看，比起那些不懂得程序员，一个理解基本商业规则的程序员将会更有价值。
（4） 不要因为枯燥就不选修非计算机专业的课程。
我不想雇佣那些只想干有趣事情的人。
（5） 选秀有大量编程实践的课程。
计算机科学与软件开发不是一回事。
（6） 别担心所有工作都被印度人抢走。
学习编程本身事一种第一流的素质训练，可以为各种超级有趣的工作打下基础。
不管是在美国还是在印度，真正优秀的程序员依然是非常非常短缺的。
真正优秀的程序员根本不会失业。
（7） 找一份好的暑期实习工作。
（8） 寻求专业人士的帮助，培养你的自信心。
第三部分 设计的作用
11 字体平滑、反锯齿和此像素渲染
苹果公司通常认为，字体算法的首要目的是尽可能多地保持原始设计的样子，即使有损屏幕显示的清晰性，也在所不惜。
微软公司通常认为，字体的形状一定要适应像素的限制，要保证屏幕显示不模糊、容易辨识，即使字体的形状因此背离原始设计，也在所不惜。
除非受过专门训练，明确自己想要什么，否则人们挑中的就是自己最熟悉的。
12 寸土必争
商业软件——那种你卖给别人的软件——就是一种寸土必争的游戏。
为了发现可以改进的地方，你必须又一个思维定势，始终如一地用批判的眼光看世界。
13 大构想的陷阱
错误一，你掉入了一个很老套的陷阱，对自己的设想过于自信。
错误二，你在做产品设计之前就开始雇佣程序员。
14 别给用户太多的选择
你给用户的选择越多，他们就越难选择，就会感到越不开心。
15 易用性是不够的
在其他条件相同的情况下，易用性设计就是决定性的。
几个实例
如果一个软件部署社会化界面时，不考虑文化人类学，那么这个软件就很难使用，令用户恼火，不会真正地发挥作用。
设计社会化软件
用户界面的设计目标是帮助用户能够成功操作。
而社会化界面的设计目标是帮助人与人之间的社会关系能够成功运作。
推广社会化界面
良好的社会化界面设计会为我们创造更多的价值。
一个新领域
16 搭建软件社区
软件实现上的小细节会导致在线社区发展、运作、用户体验上的大差异。
论坛刚刚起步的那段时间是很关键的，你要设法增加论坛的“粘度”，让跟多的人愿意经常在论坛上晃悠，这会大大缩短论坛达到人气门槛的时间。
第四部分 管理大型项目
17 火星人的耳机
所有的浏览器都有一个“规范的”模式，称为“标准模式”。它提供对网页标准的最好支持。因为对网页标准的支持一直在不断的改善中，所以每一种浏览器的每一个版本的标准模式都不一样。
当设备有了新版本时，一定要保证它自动向后兼容以前版本的附件，保证老附件能够在新版本的设备中正常使用，就像老附件能与老设备协同工作一样。
由于你想改革，想在设备中增加新的功能和特性，所以你需要为新版本的设备专门开发一个新协议。
标准当然是很重要的，但是你不能迷信标准，你必须理解由于人会犯错，所以标准有时候会引发误解、困惑，甚至是争议。
根本就没有正确答案。
18 为什么MSOffice的文件格式是如此的复杂
为了能够在很老式的计算机上快速打开文件，二进制文件格式才被设计出来。
Office大量使用复合文档，比如插入一张电子表格。
这些设计没有考虑到数据的可交换性。设计者假定Word文件格式只能被Word读写。
这些设计必须能够反映应用程序所包含的所有复杂性。
这些设计必须能够反映应用程序的历史。
让Office为你干脏活
- 用一种更简单的格式生成文件。
- 如果你要生成的只是在Excel中能够使用的表格数据，那么考虑使用CSV格式。
- 如果你真的需要CSV不支持的工作表计算功能，那么考虑使用WK1格式。
- 如果真的一定要生成Excel特有的格式，就去找一个老掉牙的Excel版本，生成一个最小化的文件，观察那些你的输出必须包含的BIFF记录类型能被简化到什么地步。
- Word文档，可以考虑生成HTML格式。
- 如果要生成带有花哨格式的Word文档，最佳选择是生成RTF格式。
19 要挣钱就别怕脏
不管别人雇你干什么工作，你都会遇到某种不顺心的麻烦事。
如果你为“麻烦事”找到了解决方法，市场就会向你支付报酬。
编写一个设计优雅、易于使用的应用程序，同解决“麻烦事”有相仿的效果。
如果你想保持增长，不管是个人，还是公司，那么唯一的方法就是扩张自己擅长处理的业务的边界。
每当新解决了一件“麻烦事”，你的业务和市场都会有巨大的增长。
第五部分 变成建议
20 循正式日程规划
软件开发者并不喜欢做日程规划。
第一个原因是做起来比较麻烦；第二个原因是，没人相信日程规划是可行的。
分解时间
如果日程规划是以“天”为单位，甚至以“周”为单位，我就认定它是没用的。
将每个任务所需的时间控制在16小时之内，就会迫使你好好地去规划你要完成的那个任务。
追踪时间的用途
传说中完美的估计者，只存在于你的想象中。
大多数估计者都属于估计不足，但是相对值是稳定的。
对未来情况进行模拟
你真正应该是用的是蒙特卡洛方法。
不要有强迫症
哪怕是事无巨细、一切都做好记录的程序员，在估计各种工作干扰的置信区间上，准确度都远远不如循证式日程规划。
积极管理你的项目
范围渐变
在原始规划上，你应该为以下的情况流出缓冲。
（1） 新的功能设想。
（2） 对手的新动向。
（3） 整合中出现的问题。
（4） 解决各种错误。
（5） 易用性测试。
（6） 软件Beta版的测试。
我们的做法
（1） 只有第一线的程序员才能提出完成日起的估计值。
（2） 已发现错误就立即修正，将用时算入原始任务的用时之中。
（3） 防止管理层向程序员施压，要求加快开发速度。
（4） 一份日程规划就是一个装满木块的盒子。
总结
使用循证式日程规划是非常容易的。
有效的日程规划是创造优秀软件的钥匙。
21 关于战略问题的通信之六
低速CPU和小容量内存的环境
不必太在意软件的效率问题和内存占用，只要把很酷的功能做出来，然后等着硬件升级就可以了。
带宽正在变得越来越便宜。
跨平台的编程语言
完善的互动性和用户界面标准
22 你的编程语言能做到吗
最有生产效率的编程环境是那些允许你在不同层次上进行抽象的编程环境。
23 让错误的代码显而易见
你只有身处这个行业，才会知道“干净”的全部意思。
程序员的3种境界。
（1） 分不清什么是干净的代码，什么是不干净的代码。
（2） 对干净的代码有一个肤浅的认识，主要看它们是不是符合代码书写规范。
（3） 能找出很神秘的不干净代码。
（4） 精心构建代码，发挥洞察力，将它们写得清晰易懂，不容易出错。
一个例子
XSS，绝不能信任用户通过表单发送的任何字符串，绝不能直接就拿来使用。
所有用户输入的字符串都是不安全的，任何不安全的字符串都必须经过编码才能输出。
可能的解决方案1
当用户输入的数据一传进来，就立刻对所有的字符串进行编码。
要是你想将用户输入的字符串出存在某个数据库中，那么就应该直接储存，而不是储存编码后的HTML代码。
可能的解决方案2
只有输出字符串时才进行编码。
有时候，在你的代码中会有一些HTML的小片段，你是不能对它们进行编码的。
正确的解决方案
所有来自用户的字符串都必须出存在变量（或数据库）中，而且变量名必须以“us”（unsafe string，不安全的字符串）起首。另一方面，所有已经经过HTML编码的字符串，活着已知来源安全的字符串，都储存在变量名以“s”（safe string，安全的字符串）起首的变量中。
重命名（或封装）Request和Encode函数为UsRequest和SEncode。
将Write重命名为WriteS，将SEncode重命名为SFromUs。这样就使得错误更明显。
一条通用规则
- 尽量将函数写得简短。
- 变量声明的位置离使用的位置越近越好。
- 不要使用宏去创建你自己的编程语言。
- 不要使用goto。
- 不要让右括号与对应的做括号之间的距离超过一个显示屏。 让与一行代码相关的所有信息尽可能地靠拢，缩短它们之间的物理距离。
寻找一种代码的书写规范，让错误的代码变得容易被看出。让代码中的相关信息在显示屏上集中在一起，是你能够当场发现和改正某些种类的错误。
匈牙利命名法
第六部分 开办软件公司
24　Eric Sink on the Business of Software的前言
当你亲身经历新生意的慢慢成长，你会感到一种难以置信的激动。那是一种快乐，看着每一项健康的生意都像有机物那样地生长。
25　Micro-ISV: From Vision to Reality的前言
如果你说不清楚你的软件解决的什么棘手的问题，就不要去开软件公司。
不要独自一人创办公司。
一开始不要抱太高期望。
26 飚高音
开办软件公司的真正目的应该是将资本转化为有用的软件。
最好的工作条件->最好的程序员->最好的软件->利润！
软件质量的改进会创造出新价值，而且价值创造的速度要快于成本提升的速度。
作业的质量与所花费的时间基本上是不相关的。
等等，我还没说完
等等，我还是没说完
不管平庸的程序员工作多长时间，他们做出来的东西都无法像优秀程序员做得那么好。
风格。开心。情感的诉求。这些就是大热门产品的成功要素，不管这种产品是软件还是电影还是消费类单子产品。

第七部分 经营软件公司
27　仿生学办公室
（1） 个人办公室，带有可以关上的门。
（2） 许多电源接口。
（3） 方便地转接各种数据线。
（4） 办公室可以用来“结对编程”。
（5） 显示器不应该靠着一堵墙摆放。
（6） 办公室应该是一个窝，一个能够很愉快度过时间的地方。
28　他山之石，不可攻玉
一个好的软件架构师只会使用那些“可以被信任”或“可以被维护”的工具。你百分百确信它会正常运作。
29 简化性
自力更生时迫不得已的选择并不是一个好的长期战略。
将iPod的成功归因于简化的功能是不正确的。
最能增加收入的就是推出一个带有更多宫恩年过的新版本。
30　揉一揉，搓一搓
代码重构。
（1） 不添加任何新功能。
（2） 无论何时向原码库提交代码，都要保证程序依然能够完善地运行。
（3） 只做一些合乎逻辑的变换，几乎都是机械性的，而且能够立刻确定不会改变代码行为。
代码整理方法的所有优点。
（1） 它的耗时大大少于一次彻底的重写。
（2） 没有引入任何新的错误。
（3） 在任何时间，如果有必要，都可以停下来，把程序交出去。
（4） 工作进度完全可以预测。
（5） 向现在的代码中加入新功能实施起来容易多了。
31　组织beta测试的十二个最高秘诀
（1） 开放式的beta测试是没用的。
（2） 要想找到那些能够向你反馈意见的测试者，最好的方法是诉诸他们“言行一致”的心理。
（3） 不要妄想一次完整的beta测试的所有步骤能够在少于8-10周的时间内完成。
（4） 不要妄想在测试中发布新的软件版本的频率能够快于每两周一次。
（5） 一次beta测试中计划发布的软件版本不要少于4个。
（6） 如果在测试过程中你为软件添加了一个功能，那么哪怕这个功能非常微小，整个8个星期的测试也要回到起点，从头来过，而且你还需要再发布3个或4个新版本。
（7） 即使你有一个申请参加beta测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见。
（8） 我们制定了一条政策，所有向我们提交反馈意见的测试者都将免费获赠一份正版软件。
（9） 你需要的严肃测试者（即那些会把反馈意见写成3页纸发送给你的人）的最小数量大约是100人左右。
（10） 你必须批准1500份参加beta测试的申请表，因为这样才能产生300个严肃测试者。
（11） 大多数beta测试的参与者只是在第一次拿到这个程序的时候才会去试用一下，然后就丧失了兴趣。
（12） 不要混淆技术beta和市场beta。

32　建立优质客户服务的七个步骤
每件事都有两种做法
一种是表面的、快速的解决方法，只求把问题解决了了事。
第一个含义。技术支持团队必须能够与开发团队直接沟通，这很关键。
第二个含义。所有常见的和容易的问题都被解决了，留下来的都是一些非常罕见的和奇特的问题。
建议吹掉灰尘
不是直接要求他们去检查某个设置，而是告诉他们先改变这个设置，然后再改回去，目的是“确保这个设置被保存进了软件”。
让客户迷上你
客户遇到问题，你帮他解决了，客户实际上变得比没有问题时还要满意。
承受责备
“这是我的错”这五个自由这么大的威力，能够在数秒之内改变我的情绪。
学会说软话
学会做木偶
贪婪让你一无所获
（再附送一条）为客服人员提供职业发展道路
你需要非常称职的人与客户交谈。
第八部分 发布软件
33　挑选发布日期
软件开发周期的基本规则。
（1） 确定发布日期，这个日期可以根据客观情况也可以根据主观愿望进行选择。
（2） 列出软件要实现的功能，然后按照优先顺序排序。
（3） 每当你落后于预定进程时，就把排在最后的功能砍掉。如果你忘了按照优先顺序部署功能，你就会把一切搞糟。
如何挑选发布日期。
（1） 经常发布稍作改进的版本。极限编程的方法，对于客户数量较少的小团队开发项目。
（2） 每12到18个月发布一次。上架销售的商业软件和桌面应用。适用于有大型开发团队和成千上万名顾客的软件。
（3） 每3年到5年发布一次。超级庞大的软件系统和平台。
较短的发布周期会较快地得到顾客的反馈。
如果你已经有了大量的付费用户，那么你最好不要太频繁地发布新版本。
对于那些有几百万用户和几百万整合点的软件系统，最好偶尔才发布新版本。
一个应用程序的行为方法与用户期待的方式一致，那么他就是易用的。
34　软件定价
一些经济学理论
市场分割：根据你的顾客愿意支付的价格将他们分成不同的组，从每个顾客身上攫取最大的消费者剩余。
虽然市场分割是一种“获取消费者剩余”的有用工具，但是长期来看，对你的产品的形象也会产生显著的负面效应。
坏主意之一：网站许可证。你在将最大的价格优惠不偏不倚给予那些最大的客户，而他们实际上是愿意付给你最多钱的人。
坏主意之二：“你有多少钱”定价法
软件的定价有三种方式，分别是免费、廉价和高价。
事实上，你连需求曲线向下倾斜都无法保证。
物有所值。
第九部分 修订软件
35　五个为什么
服务器稳定性有两个极端，一个是“极端不可靠”，服务一次又一次地中断，简直愚蠢至极；另一个是服务稳定性“极端可靠“，你花了几百万美元，终于将每年的”正常运行时间“增加了一分钟。在两个极端之间，存在一个服务稳定性的最佳位置，即所有被预计到的突发情况都已经事先做好了准备。
当某个地方出错的时候，你就问为什么，一遍遍的问，直到你找到根本性的原因为止。
36　确定优先顺序
不能采用的方法一。你发现你开发某个功能只是因为你答应过一个顾客。有两种可能，一种可能是你有一个无法无天的销售员，另一种可能是你正在走向开发“个性化软件”这条危险的道路。
不能采用的第二种方法。不要因为有些事情不得不做，你就去做。
不去理会那些相对不重要的事，把它们留在那里。