Carl 的必读书单

# 阅读 来源：https://carlkolon.com/reading/ ## 卡尔的必读清单 作为一名工程领导者，我经常给团队发送文章，并开玩笑地称之为“必读材料”。我的目标是帮助大家消化其他程序员可能遇到过类似挑战的智慧结晶。应大家的要求，我把这份清单放在这里，供任何感兴趣的人参考！ 这份清单上的大多数文章之所以入选，是因为它们提出了我认为对如何打造优秀软件至关重要或富有洞见的观点。其中有些观点强化了我对某些事情的看法（例如，ORM 很糟糕，前端应该保持简单）。你可能会不同意！但至少你 hopefully 能从中获得一些有价值的东西，即使只是让你觉得自己持相反观点。 这些文章是技术性的，如果你不是程序员，可能不会觉得它们有趣。 这份清单可能有点令人望而生畏，所以我在最喜欢的文章上标注了星号。我还为每篇文章写了简短摘要，说明为什么我认为它很重要。 ## 编码实践 ### ⭐The Grug Brained Developer (https://grugbrain.dev/) 如果只能向新老程序员推荐一篇文章，那一定是这篇。复杂性是坏东西。 ### The Wrong Abstraction (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) 看到代码重复时，我们很容易立刻想通过合并来消除它。这篇文章改编自一场关于面向对象代码分解的2014年演讲 (https://www.youtube.com/watch?v=8bZh5LMaSmE)，讨论了在这种情况下可能不合适的场景。你需要理解这一点，才能有效反驳那些一心想要处处创建“单一事实来源”的编程代理。 ### Complexity Budget (https://htmx.org/essays/complexity-budget/) 当项目变得过于复杂时，进展似乎会突然停滞。这篇文章是关于理解这一现象，并尽可能长时间地延缓它的到来。 ### Locality of Behavior (https://htmx.org/essays/locality-of-behaviour/) 程序员（以及编程代理）经常试图通过创建大量辅助函数来实现关注点分离（SoC）或消除代码重用。这与行为局部性之间存在权衡，行为局部性原则鼓励我们在只看单个代码单元时，尽可能让代码的行为显而易见。 ### Yagni (https://martinfowler.com/bliki/Yagni.html) 带着对未来功能的猜测进行开发，基本上总是一个坏主意。 ### Parse, Don’t Validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) 这篇需要花点功夫才能理解，但其核心理念是：如果你要确保某份数据具有某个属性，就应该直接将该属性编码进对象的类型中。这样，那些会破坏该断言的代码改动会在编译期抛出类型错误，而不是在运行期抛出值错误。 ## 平台 ### ⭐Steve Yegge’s Google Platforms Rant (https://gist.github.com/chitchcock/1281611) 这里有很多非常棒的内容，尤其是关于可访问性和软件组织搭建方面的。我并不建议每家公司都强制执行“贝索斯指令”，但你应该批判性地思考，是否能够以可编程的方式向其他团队暴露自己服务的功能。而且读起来也很有趣。 ## 前端 ### ⭐HATEOAS (https://htmx.org/essays/hateoas/) 在 Web 应用中，状态通常被编码并存储在与前端标记和后端都分离的地方（例如，使用 React 的 `useState`）。通常情况下，将状态和用户允许的操作直接存储在提供给用户的 HTML 中，并从中派生，会更合理。这与 REST API 的原始概念密切相关（大多数现代的“REST”API 实际上并未遵循 REST 约束 (https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/)）。我自己也在我的网站上写过关于 HATEOAS 的简短文章 (https://carlkolon.com/2026/01/27/jfmm-semantic-search/#hateoas)。 ### Components and Hooks must be pure (https://react.dev/reference/rules/components-and-hooks-must-be-pure) 我看到人们从编写后端代码转向编写 React 时最大的问题，就是他们试图*命令式*地编写前端。也就是说，他们试图一行一行地告诉计算机该做什么。这通常涉及对状态和副作用（在面向对象编程中很常见）的过度使用。相反，前端应该采用*声明式*的方式。也就是说，你应该告诉计算机*你想要得到什么结果*。为了支持这一点，（现代）React 是围绕函数式编程风格设计的。每个组件都是一个函数，除非确实必要（此时需要使用 hooks），否则应避免状态和副作用。我建议阅读所有 React 文档，但如果只想专注一篇，这是最好的。 ### Understanding useMemo and useCallback (https://www.joshwcomeau.com/react/usememo-and-usecallback/) `useMemo` 和 `useCallback` 是 React 中最容易被误用的 hooks（也许仅次于 `useEffect`），无论是代理还是人类都喜欢到处乱加。这篇文章是一份关于在哪些地方它们确实必需的指南。 ### Hypermedia Systems - Components of a Hypermedia System (https://hypermedia.systems/components-of-a-hypermedia-system/) 如果你想写出好的前端，理解 HTML 所基于的模型是非常有价值的。这是一本很棒的书中的很棒的一章，它将帮助你最大化地利用浏览器的设计，而不是把 HTML 视为“一种笨拙的、遗留的标记语言，必须勉强用来构建那些日益完全基于 JavaScript 的 Web 应用中的用户界面。” ## 数据库 ### ⭐The Vietnam of Computer Science (https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf) 我是一个认证的 ORM 憎恨者。我认为 ORM 对新项目很有诱惑力，但很快就会开始引发性能问题和混乱。例如，请看这篇关于扩展 Postgres 的 OpenAI 文章 (https://openai.com/index/scaling-postgresql/)： > 许多有问题的查询是由对象关系映射框架（ORM）生成的，因此仔细审查它们生成的 SQL 并确保其行为符合预期非常重要。 这是我所读过的反对 ORM 的最佳文章，尽管篇幅很长，我还是强烈推荐。 ### Wikipedia - The Object-Relational Impedence Mismatch (https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch) 这是我在反对 ORM 运动中的又一些弹药。这篇更技术性但更简洁，如果你只想看要点，可以读这篇。 ### Introduction to PostGIS - Geography (https://postgis.net/workshops/postgis-intro/geography.html) PostGIS（以及地理空间数据库）需要一点时间来适应。当你构建基于地图的数据可视化工具时，最好了解你正在使用的新数据类型。PostGIS 是一个很棒的数据库，它的基础数据类型是 `geography`。 ### Postgres Docs Chapter 14 - Performance Tips (https://www.postgresql.org/docs/current/performance-tips.html) 当你的数据库开始变慢时，这是一篇值得*已经读过*的好文章。在我看来，知道如何使用 `EXPLAIN` 和 `EXPLAIN ANALYZE` 与知道如何使用调试器同等重要。 ### Paging Through Results (https://use-the-index-luke.com/sql/partial-results/fetch-next-page) 大多数人在构建分页系统时使用 `LIMIT` 和 `OFFSET`。如果你要分页浏览大量数据，这些方式会变慢（尤其是在加载页数较大的页面时）。这是一篇很好的概述，介绍了绕过这个问题的其他一些选项。我也在我的网站上讨论过这一点 (https://carlkolon.com/2026/01/27/jfmm-semantic-search/#pagination)。 ## 异步编程 ### A Conceptual Overview of asyncio (https://docs.python.org/3/howto/a-conceptual-overview-of-asyncio.html) 很多人是被直接扔进异步编程中的，并不真正理解发生了什么，而是边做边学。这常常导致非常基础的 asyncio 错误，比如在异步函数中进行阻塞调用。这是一篇很好的文档文章，应该能让你更清楚 asyncio 在底层做了什么，从而教你如何最好地使用它。 ### What Color is your Function? (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) Bob Nystrom 是我最喜欢的编程作者之一。这篇文章展示了异步编程系统如何经常存在根本性缺陷。你能做的并不多（除了换一种语言），但这至少会教你，你遇到的某些异步编程限制是根本性的，而不仅仅是技术问题。 ## 编码 ### The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) (https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/) 如果在我职业生涯早期读到这篇文章，我会节省数百小时，不用去错误地解析从互联网收集的数据。 ## 书籍 这些书籍塑造了我对编程、设计和管理软件项目的看法。 ### The Design of Everyday Things (Amazon (https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654)) 很多人似乎认为“设计”就是让东西看起来漂亮。实际上，设计是关于预测用户的需求，并让你的产品尽可能好地满足这些需求。通常，“设计”的这第二种含义与第一种相悖，在这种情况下你应该选择第二种。书中早期关于“诺曼门”的例子很好地说明了这一点，同时还有一句讽刺的观察：那些门“可能赢得过设计奖”，尽管作者自己都搞不清楚它们怎么用。 ### Designing Data-Intensive Applications (O’Reilly (https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/)) (Amazon (https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1098119061)) 喜欢这本书已经成为一种梗，但它确实非常棒。它也是少数几本适合作为有声书来听的编程书之一。我最喜欢的章节是第7章（事务）和第10章（批处理）。虽然可能有人不同意，但我认为这对数据库来说也是一个很好的入门读物，它会让你认真思考在数据系统中你到底想优化什么（即使你不是在为庞大的用户群体服务）。 ### Crafting Interpreters (免费在线阅读 (https://craftinginterpreters.com/)) 这是一本很棒、鼓舞人心、有趣的书籍，教你怎么构建一个解释器：先用 Java 为了简单，然后用 C 为了性能。虽然你可以边读边直接编写 Java 代码，但我认为更好的做法是尝试用你选择的另一种语言实现这个解释器，这样你就需要更多地动脑。我用的是 Rust (https://github.com/cckolon/rlox)。 ### Category Theory for Programmers (免费在线阅读 (https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/)) (订购精装版 (https://www.blurb.com/b/9621951-category-theory-for-programmers-new-edition-hardco?srsltid=AfmBOorML0osX9pBLA7bSJCjMebmXrBVUktX6803wMuRKoSmBMO4n8Jf)) 虽然这本书有点硬核，但它是我所见过的范畴论最佳入门读物（不过如果你追求严谨，可能还是要去搜一下一些形式化定义）。如果你想写出好的函数式代码，同时又能用“functor”和“monad”这样的词在同事面前炫技，那就读这本吧。 ### The Mythical Man-Month (Amazon (https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959)) 这本书出版于1975年（！），最近一次修订是在1995年，但它到现在仍然极其相关。事实上，随着程序员装备上 AI 工具，有些章节（比如第4章，“系统设计中的贵族制与民主制”）现在看起来比1995年时更具现实意义。如果你想管理一个编程项目并让它成功，就读这本吧。