rolt的专栏

一些不知柴米油盐贵的人，以为市场和客户极其宽容，普天之下皆我妈，爱怎么试错都可以。

Wiley 2025年出版的书Unlocking Python: A Comprehensive Guide for Beginners（解锁Python：初学者的全面指南）

O’Reilly 2025年出版的书Fundamentals of Software Engineering: From Coder to Engineer（软件工程基础：从编码人员到工程师）

The Pragmatic Programmers 2026年出版的书Advanced Functional Programming with Elixir: Model Behavior, Manage Complexity, and Maximize Maintainability（Elixir高级函数式编程：建模行为、管理复杂度与最大化可维护性）

本文只说明该书引用《人月神话》的事实，不代表推荐阅读或不推荐阅读该书。

本文只说明该书引用《人月神话》的事实，不代表推荐阅读或不推荐阅读该书。

2026年是《人月神话》出版51周年。51年后，《人月神话》依然被新出版的书籍引用。

难怪Brooks法则会说：“给一个已经延期的项目增加资源，只会让它更延期”……单是沟通本身就已经是半个战役了

本文只说明该书引用《人月神话》的事实，不代表推荐阅读或不推荐阅读该书。

但在Licklider的时代，单是设计一个操作系统就已经是一项史诗般的壮举（Brooks，1975）。此外，即使是早期构建AI系统的尝试，也必须面对这样一个事实：

这到底是什么神作？点开看，访问量目前还不到3000。

书中谈到对象的分类时，也使用了fuzzy，这一次翻译对了：

错译的原因是没看懂planar这个词。

或者就把《软件方法》的题目做对60%（就算用批判的眼光来做题也行），以前那些花样百出的奇谈怪论很可能就消失掉了。

当看向十年后的地平线时，我们看不见银弹。

翻译时，没有理解mass market（大众市场）的意思，从而导致误认为避免雷同构造的是要出售的产品。

随着AI足够强大到弥补我们的短板，我们只需要根据我们最强的天赋和兴趣来选择服务对象，投入过去无法投入或不敢投入的战场。

理解并管理问题固有的复杂性——仍然落在人类的肩上。用 Fred Brooks 的经典说法，AI 解决的是偶然的，而非内在的开发困难。

Microsoft依然很稳，《人月神话》也依然在引用，像下面这本2025年出版的书：

目前为止正式出版的软件开发各领域中文书籍中对《人月神话》的引用，分享给大家

二十三年前我们没看懂《人月神话》幻灯片》-pdf文件，共127页。如果需要提取码：umlc。已上传至优快云资源。本文件会不定期更新。

UML和模式应用 原书第3版 典藏版》

摘录软件开发领域的各种中文书籍中对《人月神话》的引用片段，分享给大家。

Tanenbaum在其操作系统教材第五版中，用了7页来概括《人月神话》的内容，并出了题。

正如Brooks所说，尽管软件吞噬了企业，仍然没有银弹式的答案。

2004年《企业应用架构模式》中译本和2024年《企业应用架构模式》典藏版译本的页面

主要靠经理们的直觉来认证的估算

作者谈到编程工作的乐趣时，用了一个词来类比编程工作，这个词是：

“乔布斯不理会顾客”，“张小龙不看用户反馈”就类似于“有礼貌的固执”，但真相可能是：

《人月神话》之后，UMLChina又和清华大学出版社合作，翻译了《人件》和《最后期限》

第7章此处的producer，原来翻译是“产品负责人”。当然，这个也可以，意思是他的角色是最大的，不过，这个词应该是从娱乐业借用的“制作人”——音乐制作人、电影制作人……。

《人月神话》里面大段引用的《出卖月亮的人》

可以和手上的各种版本对照修改

机械工业出版社即将在2024春节前后推出《UML和模式应用（原书第3版）》的典藏版。

除了修订之前译文未发现的错误，还根据原书历次重印归纳的勘误修订译文。

在"The Mythical Man-Month"（人月神话）第2章的开头，放上了一份菜单，背后的意思是：

DDD领域驱动设计批评文集欢迎加入“软件方法建模师”群《软件方法》各章合集

OS/360调度程序是很好的，但它几乎完全没有受到OS/360对远程作业入口、多道程序和永久驻留交互子系统的需要的影响。在这些地方，一种型号的结果可能与另一种型号不同，给定型号的一份副本可能与另一份副本不同，或者在工程变更后，副本甚至可能与自身不同。或者源于某个模型与其他模型的差异，某个给定模型的复件和其他复件的差异，甚至是工程上的变更引起的复件自身上的差异。语法和规则的表达可以不需要具体的设计实现，但是特定的语义和意义通常会通过一段实现该功能的程序来定义。对于定义的撰写，有许多小决定是不需要充分辩论的。

所以，在雄伟的哥特式教堂上，依附着祥和的诺曼底风格十字架，它在显示荣耀的同时，展示了同样属于建筑师的骄傲。（3）Conceptual，概念上的，Conceptual Integrity应译为“概念上的完整性”或者简略为“概念完整性”，不宜译为“概念的完整性”，这个相当于Integrity of Concept。（5）此处是批评不是赞扬，呼应上文的“避免轻浮炫耀”，pridefulness在这里应该是自负或傲慢的意思，是七宗罪之一，和后文的神的拯救呼应。（1）glory of God，神的荣耀。

而且，非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出有力的、看似可靠的和规避风险的估计。或者，在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多。一个不是由量化方法得来、缺乏数据支持，主要靠经理们的直觉来认证的估算，让人很难对它做出有力、合理而且带有职业风险的辩护。更可靠的估算基础出现之前，每个经理需要挺直腰杆，捍卫他们的估算，确信自己可怜的直觉总比从期望派生出的估算强。软件顾客也面临同样的选择。