> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20220102-ruan-jian-yu-xi-tong-guan-li/book.md).

# 书评：《编程智慧：编程鬼才的经验和思考》

* 原文：[A review of The Kollected Kode Vicious](https://freebsdfoundation.org/wp-content/uploads/2022/03/reuschling_practical_ports.pdf)
* 作者：**BENEDICT REUSCHLING**

亲爱的 Practical Ports，

> 我是否应该抽时间阅读 George V. Neville-Neil 的《编程智慧：编程鬼才的经验和思考》，而不是一本关于我工作所需的新编程语言的书？我没有太多时间阅读，所以需要谨慎选择。我也不明白，像 KV 这样使用笔名而非真名的人，如何能让人认真对待，特别是当他给别人提供如此主观的建议时。
>
> —— 一位近来时间不多的怀疑读者

亲爱的怀疑者，

你是否听说过 Alice Addertongue 或 Silence Dogood？或者 Poor Richard 有没有让你想起什么？这些都是本杰明·富兰克林（Benjamin Franklin）使用的笔名。在富兰克林的时代，笔名和漫画形象是非常常见的，尽管通常很容易知道是谁在背后写作。这些不同的漫画形象不仅让富兰克林能够为他的读者（即他自己报纸的读者）提供多角度的看法，还允许他运用夸张、讽刺和奇思妙想来娱乐读者并影响他们的观点。因此，使用化名和人格写作并不是新鲜事，实际上，既然你在给 Practical Ports 写信，你也在参与其中。

在我们讨论书籍之前，下面先解决你抽出时间读书的问题。“每个人都有时间。别再看该死的《迷失》了！”—— Gary Vaynerchuk，2008 年于 Web 2.0 Expo NY <https://www.youtube.com/watch?v=EhqZ0RU95d4>

不过，好吧，撇开这个，我可以理解如今时间很难抽出。而且，能读的书毕竟有限（如果是好书的话，那就更棒了！）。无休止地刷新闻或社交媒体不算是阅读，陷入 Youtube 的无尽循环也不算。书籍仍然是知识和娱乐的重要来源——或许现在比以往任何时候都更为重要——这就是为什么我抽时间来审阅这本书。即便在充斥着电子信息的互联网海洋中，翻开纸质书页仍然能吸收永恒的智慧并享受乐趣。

现在，关于你是否应该为《编程智慧：编程鬼才的经验和思考》这本书腾出一些时间的问题。对于尚未接触 KV 专栏的读者，我应该解释一下，这本书是 KV 在 ACM Queue 专栏中同名专栏的合集，按照主题分组。作者多年写作这些专栏，并将最好的文章收集在书中，按主题进行组织，并附上简短的介绍。至于他是如何让计算机科学巨匠唐纳德·E·克努斯（Donald E. Knuth）为书作序的，或许永远是作者的秘密。简直是被封爵了！我非常喜欢章节开头的引言，这里有不少能够概括你即将阅读的内容的引用。（例如：哦，Bullwinkle，那招永远不管用！— Rocky J. Squirrel）

如果你从未读过 KV 的专栏，要知道，它们遵循的是备受推崇的问答/建议专栏格式——这个格式古老得可以追溯到本杰明·富兰克林的解构和重构方法，当然，也可以追溯到苏格拉底。书中的信件/问题呈现的是一个困惑或困扰的人向 KV 寻求建议的情境。这些问题既真实又相关，常常和我从学生那里听到的类似。一些较晚的专栏显然是基于真实的信件，而一些较早的专栏则是代笔写作。在所有情况下，答案/建议都会回应问题，解释、化解、解构、重组或打消假设，同时为主题提供新的见解。提供的意见通常是出于良好意图，并给出所期望的建议。这些信件中的许多（如果不是全部的话）可能以禅宗故事中常用的词语结尾：“于是，学生得到了启发。”

查看目录，你会看到以下几组主题：

* 手头的代码 —— 讨论程序员（像你）必须面对的日常烦恼和思考——从分配过多内存、异常处理（或缺乏处理）到正确的日志记录和编码风格讨论。本章主要吸引程序员，对于那些偶尔使用计算机、好奇为什么互联网不起作用的用户不太适合。
* 编程难题 —— 探讨更为哲学性的问题，比如什么是好的编程语言，如何避免无休止地包含文件的意大利面条式代码，为什么测试很重要，以及代码扫描器和调试策略等元主题。所有这些都值得一读，如果你有几年的编程经验，你肯定会在其中找到一个熟悉的故事。如果你曾问过自己为什么现在的事情是这样，那接下来的章节将为你解答。
* 系统设计 —— 讨论人们在设计我们日常使用的系统，或编写未来会让我们恼火的系统时所做的选择（大多是糟糕的）。永恒话题如身份验证与加密、跨站脚本攻击、钓鱼和感染（后者指的是计算机系统），以及 UI 设计将让你频频点头同意，同时也会对糟糕设计的典型例子摇头。我留给你自己去发现为什么 Java 会出现在这一章节。
* 机器对机器 —— 讨论延迟、扩展失败、协议设计以及日益增长的标准列表。如果你认识这位作者或听说过他，那么你不会感到惊讶，这一部分并不是在谈论网络如何连接这些机器。如果你觉得这很让人不安，那就等着读下一部分吧……
* 人类对人类 —— 思考如何命名你的主机，别让你的自尊心介入，代码面试问题，以及“油漆小棚”现象（即无关紧要的事物成为争论焦点）。人们为计算带来了许多有趣的特质——如果它们只是好特质就好了。

在每一章中，作者通过故事揭示洞察力和经验，警示和教育读者。尽管这些故事常常带有些许抱怨（或许是因为看到了太多类似的情况），但没有一页让你觉得事情已经无望。相反，书中充满了实用的建议，夹杂着个人的偏好和推荐，并且始终以机智和幽默的方式传达。我能想象这本书有两个很好的用途。一个是作为轻松娱乐的阅读，另一个是作为参考书。专栏内容足够简短，可以在短暂的休息时（搭配你喜欢的饮料）或睡前（噩梦也无妨）阅读。把书放在容易拿到的地方，这样必要时，你可以迅速重读相关章节。另一个想法是，当争论发生或面临待定设计决策时，把它交给你的同事和同行。“翻看《Vicious》，提醒自己什么是不该做的”，当讨论陷入僵局，需要新视角时，或许可以这样说。经验丰富和新来的同事都会在这些专栏中找到有趣且相关的内容，他们会点头表示认同（我也经历过），或微笑着想起有趣的轶事。

现在，回到你是否应该在有限的阅读时间里选择《编程智慧：编程鬼才的经验和思考》而不是一本新编程语言书籍的问题，我会说：“是的。”我认为你应该阅读 KV 的书，但不要期望从中找到“使用这个巧妙的代码片段让代码更快”或“使用 Emacs 作为编辑器会让你生产力提升千倍”之类的建议。另一门编程语言可能会在简历上看起来不错，但最终，这些不过是行业工具罢了。我们所做的事情远不止编写代码！这本书将为你阐明这一点，展现这个行业的喜怒哀乐。你的阅读体验可能不同，但我认为阅读这本书并内化其教诲，会对你大有裨益。最后用另一句引言结束：

> “去年，一位愚僧。 今年，依然如故。”
>
> ——日本禅宗诗人良宽大愚

***

**BENEDICT REUSCHLING** 是 FreeBSD 项目的文档提交者，也是文档工程团队的成员。他是 FreeBSD 基金会董事会的副主席。过去，他曾任两届 FreeBSD 核心团队成员。他在德国达姆施塔特应用科技大学管理一个大数据集群，还为本科生教授“Unix for Developers”课程。Benedict 也是每周 bsdnow\.tv 播客的主持人之一。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20220102-ruan-jian-yu-xi-tong-guan-li/book.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
