DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

---

2001年，我们翻译《人月神话》的时候，由于水平有限，译文中存在不少错误。

这些年，随着阅历的增长，在重读的时候偶尔也会有“原来这里的意思是这样啊，之前搞错了”的感受。

2023年，清华大学出版社推出《人月神话》典藏纪念版，大幅度修正了译文。在此，把修订译文时的一些联想和感受写成若干文章分享。

******

我们先来做一道题：

[单选]

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

A) 很多项目经理还不如餐厅的厨师。客户一催，他们就打乱原先的计划。

B) 开发人员要像餐厅厨师做菜一样，追求软件的高质量。

C) 一道菜需要烹调多长时间，并不因为厨师的增加而变化。也就是说，人（人数）和月(时间)不能简单替换。

D)软件开发就像做菜。厨师要灵活组合少量种类的食材，做出比食材种类要多得多的各种花样的菜肴。

|

|

|

|

|

|

答案是A。

菜单上文字的译文是：

正文中，呼应这份菜单的原文有这么一句：

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.

我们的原译文是：

第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作。

原译文没有领会到“courteous stubbornness（有礼貌的固执）”的意思，而且还误认为“stubbornness”是针对估算（estimates）来说的。

新译文是：

第三，由于对自己的估算缺乏信心，软件经理通常缺少安托万大厨那样的有礼貌的固执。

**********

其实，“有礼貌的固执”只是表面现象，背后是涉众的排序以及涉众利益的提炼。

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

不理会对自家产品而言排序较低的涉众的意见；

即使排序较高的涉众，也不能照搬涉众的意见，而是要提炼背后的涉众利益。

我们用“涉众”的概念取代不严谨的“顾客”、“用户”。

详细知识，参见《软件方法》第2章和第7章。

**********

但是，这样做是有风险的。

就拿安托万的厨师来说，顾客说要这样，他有礼貌地劝顾客最好那样，如果搞砸了，那就要被投诉或炒鱿鱼了。

这就是《人月神话》接下来要说的“带有职业风险的辩护”。

这一点，下一篇文章再说。

UMLChina公众号精选（20240108更新）