黑客与画家 | 8.8
黑客与画家
黑客行为必须包含三个特点：好玩、高智商、探索精神。只有其行为同时满足这三个标准，才能被称为“黑客”
《黑客：计算机革命的英雄》（Hackers: Heroes of the Computer Revolution）一书中，将黑客的价值观总结为六条“黑客伦理”（hacker ethic），直到今天这几条伦理都被视为这方面的最佳论述。
- 使用计算机以及所有有助于了解这个世界本质的事物都不应受到任何限制。任何事情都应该亲手尝试（Access to computers – and anything that might teach you something about the way the world works – should be unlimited and total. Always yield to the Hands-On Imperative!）
- 信息应该全部免费（All information should be free.）
- 不信任权威，提倡去中心化（Mistrust Authority – Promote Decentralization.）
- 判断一名黑客的水平应该看他的技术能力，而不是看他的学历、年龄或地位等其他标准（Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.）
- 你可以用计算机创造美和艺术（You can create art and beauty on a computer.）
- 计算机使生活更美好（Computers can change your life for the better.）
黑客与画家的共同之处，在于他们都是创作者。黑客和画家都是试图创作出优秀的作品。他们本质上都不是在做研究，虽然在创作过程中，他们可能会发现一些新技术
当多个画家共同创作一幅作品时，每个人画的部分都是不一样的。通常来说，大师负责画主要任务，助手们负责画次要任务和背景。但是，你肯定找不到某个部分是两个人一起画的。我认为，这也是多人共同开发一个软件的正确模式。需要合作，但是不要“合”得过头。如果一个代码块由三四个人共同开发，就没有人真正“拥有”这块代码。最终，它就会变得像一个公用杂物间，没人管理，又脏又乱，到处堆满了冗余代码。正确的合作方法是将项目分割成严格定义的模块，每一个模块由一个人明确负责。模块与模块之间的接口经过精心设计，如果可能的话，最好把文档说明写得像编程语言规范那样清晰
用户第一次使用你的软件的时候，不会预先做好功课，他们没有任何准备就开始用了，所以软件的使用方式最好能符合用户的直觉，别指望用户去读使用手册
源代码也应该可以自己解释自己。如果我只能让别人记住一句关于编程的名言，那么这句名言就是《计算机程序的结构与解释》一书的卷首语：程序写出来是给人看的，附带能在机器上运行
把代码写得便于阅读，并不是让你塞进去很多注释。我想引申一下 Abelson 和 Sussman 的那句话：“程序写出来是为了让人看懂它的算法，附带告诉计算机如何执行。”一种好的变成语言应该比英语更容易解释软件。只有在那些不太成熟、容易出现问题的地方，你才应该加上注释，提醒读者注意那里，就好像公路上只有在急转弯处才会出现警示标志一样
另一条路
在大多数软件公司，客服人员是边缘人，黑客则是呼风唤雨的主宰者。这些公司有各种各样的 bug 报告流程，但是几乎都是单向式的：使用者打电话给客服人员报告 bug，客服人员填写某种形式的表格，传递给程序员（可能会经质量监控部门之手），程序员把 bug 写入待解决问题的清单
客户支持实际上就是质量监控，也是某种程度的市场营销。除了记录 bug，客服人员还必须大概了解相关知识，回答与 bug 相关的一些问题、解释令使用者迷惑不解的功能等。有时，他们也扮演了使用者的代理人，我们会问他们哪个新功能是用户更想要的，他们总是能做出正确的回答
构思这种东西有一个特点，那就是它会导致更多的构思。实现某个构思，会带来更多的构思。所以，将一个构思束之高阁，不仅意味着延迟它的实现，还意味着延迟所有在实现过程中激发的构思
投资者和分析家会问，你们对未来有何计划。真实的回答是，我们没有任何计划。我们有改进的想法，但是如果我们想到应该怎么改进，就已经把它实现了。接下来六个月我们要做什么？所有能想到的最佳改进。我不知道自己是否有胆量公开这么说，但这是实话。计划这个词，只是将构思束之高阁的另一种表达方式。只要想到好的构思，我们就立刻着手实现
《人月神话》一书中所指出的，向一个项目增加人手，往往会拖慢项目进程。随着参与人数的增加，人与人之间需要的沟通呈现指数式增长。人数约来越多，开会讨论各个部分如何协同工作所需的时间越来越长，无法预见的互相影响越来越大，产生的 bug 也越来越多。幸运的是，这个过程的逆向也成立：人数越来越少，软件开发的效率将指数式增长。
管理企业其实很简单，只要记住两点就可以了：做出用户喜欢的产品，保证开支小于收入。只要做到这两点，你就会超过大多数创业公司。随着事业的发展，你自己就能琢磨出来其他的诀窍
至于如何做出用户喜欢的产品，下面是一些通用规则。从制造简洁的产品开始着手，首先要保证你自己愿意使用。然后，迅速地做出 1.0 版，并且不断加以改进，整个过程中密切倾听用户的反馈。用户总是对的，但是不同的用户要求不一样。低端的用户要求简化操作和清晰易懂，高端的用户要求你增加新功能
如何创造财富
- 从经济学观点看，你可以把创业想象成一个压缩过程，你的所有工作年份被压缩成了短短几年。你不再是低强度低工作四十年，而是以极限强度工作四年。在高技术领域，这种压缩的回报尤其丰厚，工作效率越高，额外报酬就越高
设计者的品位
- 好设计是简单的设计
- 好设计是永不过时的设计
- 好设计是解决主要问题的设计
- 好设计是启发性的设计
- 好设计通常是有点趣味性的设计
- 好设计是艰苦的设计
- 好设计是看似容易的设计
- 好设计是对称的设计
- 好设计是模仿大自然的设计
- 好设计是一种再设计
- 好设计是能够复制的设计
- 好设计常常是奇特的设计
- 好设计是成批出现的
- 好设计常常是大胆的设计
书呆子的复仇
朝着数学的方法发展
20 世纪 50 年代的编程语言到现在还没过时的原因，简单说，因为这种语言本质上不是一种技术，而是数学。数学是不会过时的。你不应该把 Lisp 语言与 50 年代的硬件联系在一起，而是应该把它与快速排序（Quicksort）算法进行类比。这种算法是 1960 年提出的，至今仍然是最快的通用排序方法
Lisp 语言诞生的时候就包含了 9 种新思想。其中一些我们今天已经习以为常，另一些则刚刚在其他高级语言中出现，至今还有 2 种是 Lisp 独有的。按照被大众接受的程度，这 9 种思想依次如下排列。
- 条件结构（即 if-then-else 结构）
- 函数也是一种数据类型
- 递归
- 变量的动态类型
- 垃圾回收机制
- 程序由表达式组成
- 符号类型。符号实际上是一种指针，指向存储在散列表中的字符串。所以，比较两个符号是否相当，只要看它们的指针是否一样就行了，不用逐个字符地比较
- 代码使用符号和常量组成的树形表示法
- 无论什么时候，整个语言都是可用的。Lisp 并不真正区分读取期、编译期和运行期。你可以在读取期编译或运行代码，也可以在编译期读取或运行代码，还可以在运行期读取或编译代码。在读取期运行代码，使得用户可以重新调整（reprogram）Lisp 的语法；在编译期运行代码，则是 Lisp 宏的工作基础；在运行期编译代码，使得 Lisp 可以在 Emacs 这样的程序中充当扩展语言；在运行期读取代码，使得程序之间可以用 S 表达式（S-expression）通信