查看原文
其他

《人月神话》译文修订明细(11)-读者可以对照修改

潘加宇 UMLChina 2024-03-10
《人月神话》译文修订明细(1)-读者可以对照修改
《人月神话》译文修订明细(2)-读者可以对照修改
《人月神话》译文修订明细(3)-读者可以对照修改
《人月神话》译文修订明细(4)-读者可以对照修改
《人月神话》译文修订明细(5)-读者可以对照修改
《人月神话》译文修订明细(6)-读者可以对照修改
《人月神话》译文修订明细(7)-读者可以对照修改
《人月神话》译文修订明细(8)-读者可以对照修改
《人月神话》译文修订明细(9)-读者可以对照修改
《人月神话》译文修订明细(10)-读者可以对照修改

第六章 传递消息(续)
原译文

外部功能,说明它们是什么

修订译文

外部功能,并且必须说明它们是什么

******

原译文

作为一种形式化定义的方法

修订译文

作为形式化定义

******

原译文

新的机器同原有的机器一致

修订译文

新的机器同现有的机器匹配

******

原译文

设计一段程序

修订译文

设计一段测试程序

******

原译文

系统的仿真装置

修订译文

系统的程序化仿真器

******

原译文

使用实现来作为一种定义的方式有一些优点。首先,

修订译文

使用实现作为定义有一些优点。

******

原译文

回答是快捷、迅速的。通过定义得出的答案,总是同所要求的一样精确和正确。但是,除了这些优点,还有

修订译文

回答迅速。答案总是尽可能精确,而且根据定义总是正确的。

******

原译文

实现体现了过多的内容:它不但描述了系统必须做什么,还声明了自己到底做了些什么

修订译文

实现作为定义体现了过多的内容:它不但描述了机器必须做什么,还说明了必须如何去做

******

原译文

这些粗糙的功能在其他的设计实现中

修订译文

这些粗糙如果在另一个实现中复制,

******

原译文

该功能确切的特性,即保存运算垃圾,成为真正定义的一部分

修订译文

后来发现,这些垃圾本质上确实是事实上的定义的一部分

******

原译文

某些快速乘法

修订译文

某些更快的乘法

******

原译文

一种更加可爱的方法

修订译文

一种美妙的方法

******

原译文

共享存储器的声明

修订译文

共享存储的声明

******

原译文

并要求编程实现编译时的一些操作

修订译文

并要求实现通过编译时操作

******

原译文

或者重新编译

修订译文

只需重新编译

******

原译文

因此,我们把会议分成两个级别:周例会和年度大会—这实际上是一种非常有效的方式。周例会是每周半天的会议,所有的结构师、硬件和软件实现人员代表,以及市场计划人员参与,由首席结构师主持。

修订译文

我们发现把会议分成两个级别很管用。第一个是每周半天的会议,所有架构师以及硬件和软件实现人员的官方代表和市场规划人员都参加。首席系统架构师主持。

******

原译文

修改意见

修订译文

修改建议

******

原译文

但是建议书

修订译文

但是建议

******

原译文

不仅仅是得出结论

修订译文

不仅仅是做出决定

******

原译文

各种方法

修订译文

各种方案

******

原译文

变更建议说明书

修订译文

变更建议书

******

原译文

正面和反面的意见

修订译文

利弊得失

******

原译文

这需要花费时间,最终所发布的结论是正式的和果断的。周例会的决策会给出迅捷的结论,使工作继续开展下去。如果任何人对结果过于不满,

修订译文

会议记录被保存下来,决定被正式、迅速和广泛地传播。每周会议的决定能迅速生效,使工作得以继续开展。如果有人很不高兴,

******

原译文

因此,大家对相关的项目内容比较了解,不需要安排额外时间对人员进行培训。

修订译文

不需要专门安排时间来让大家了解最新的情况

******

原译文

上述小组人员

修订译文

小组人员

******

原译文

并且与产品密切相关

修订译文

并且与结果密切相关

******

原译文

都要承担义务。

修订译文

都有权作出有约束力的承诺。

******

原译文

在界线的内部

修订译文

在明显界线的内部

******

原译文

一些决定没有很好地贯彻

修订译文

一些决定不再适用

******

原译文

造成了未曾遇到的问题

修订译文

造成了预想不到的问题

说明

原文unforeseen

******

原译文

有时周例会

修订译文

有时每周会议

******

原译文

公开问题

修订译文

未解决的问题

******

原译文

出席人员不仅包括体系结构小组和编程人员、实现人员的结构代表,还包括编程经理、市场和实现人员

修订译文

出席人员不仅包括架构组和程序员、实现人员的架构代表,还包括编程经理、营销经理和实现经理。

******

原译文

会议室周围的图表上

修订译文

会议室周围张贴的图表上

******

原译文

每个不同的声音都有机会得到表达,最后做出决策。通过出色的计算机化文本编辑工作(许多优秀员工的卓越的工作成果),

修订译文

各方意见都会听取,并作出决定。有了奇迹般的计算机化文本编辑工作以及许多优秀职员的工作,

******

原译文

每个人都在倾听,每个人都在参与,每个人对复杂约束和决策之间的相互关系有了更透彻的理解

修订译文

每个人的声音都会被倾听,每个人都参与其中,每个人对决策之间错综复杂的约束以及相互关系有了更透彻的理解

******

原译文

多重实现的同时开发

修订译文

多重实现的同时建造

******

原译文

这种必要性是强制规格说明的最佳代言人

修订译文

这种必要性是规约的最佳执行代理

******

原译文

手册更容易改动,并且成本更低

修订译文

手册可以更快、更便宜地变更

******

原译文

定义会更加整洁和规范

修订译文

定义会更加清晰,纪律会更为严格

******

原译文

无数结构理解和解释

修订译文

无数架构解释

******

原译文

这是一项很基本的措施。他们还需要认识到的是,

修订译文

这是至关重要的。同样重要的是,要认识到

******

原译文

这种机制不是很正式,但非常快捷和易于理解

修订译文

这种机制很不正式,但非常快捷和全面

******

原译文

测试机构/小组

修订译文

测试小组

******

原译文

充当麻烦的代言人,查明每一个可能的缺陷

修订译文

并充当魔鬼代言人,精确地指出每一个可能的缺陷

******

原译文

每个开发机构

修订译文

每个开发组织

******

原译文

独立的技术监督部门,来保证其公正性

修订译文

独立的技术审计小组,来保持开发组织的诚实

******

原译文

在最后的分析中,用户是独立的监督人员。

修订译文

归根结底,顾客才是独立的审计员。

说明

误译。原文in the last analysis

******

原译文

总会发现一些设计决策没有被贯彻执行、没有被正确理解

修订译文

总会发现一些信息没有被传递、设计决策没有被正确理解

******

原译文

出于这方面的原因,设立测试小组是使设计决策得以贯彻执行的必要手段,同样也是需要尽早着手,与设计同时实施的重要环节。

修订译文

因此,这样的测试小组是设计信息传递链中必要的一环,需要与设计一样,在早期同时运作。

******

第七章 为什么巴别塔会失败

原译文

巴比伦塔

修订译文

巴别塔

说明

后文的“巴比伦塔”都改为“巴别塔”

******

原译文

丰富的泥土和柏油沥青

修订译文

丰富的黏土和沥青

******

原译文

项目远在达到技术限制之前

修订译文

项目在达到技术限制之前

******

原译文

大家选择了孤立,而不是互相争吵

修订译文

大家宁愿孤立,也不愿互相争吵

******

原译文

现实也是如此

修订译文

今天也是如此

******

原译文

所以进度缓慢、功能不合理

修订译文

所以时间表混乱、功能不匹配

******

原译文

用法上的约定

修订译文

用法上的假设

******

原译文

正在设计监控程序,

修订译文

正在设计监控程序的主要部分,

******

原译文

覆盖功能的开发速度,它在速度上的变化成为主要的规格说明变更。因此需要从系统角度来考虑和衡量该变化,以及公开、广泛地发布变更结果。

修订译文

覆盖功能的速度,这种速度变化本身就成为了重大的规约变更,需要对外宣布并从系统的视角来衡量。

说明

误译

******

原译文

团队成员相互之间如何进行交流、沟通呢?

修订译文

团队之间如何交流呢?方式越多越好。

******

原译文

非正式途径。清晰定义小组内部的相互关系和充分利用电 话,鼓励大量的电话沟通

修订译文

非正式。清晰定义组间的依赖关系和良好的电话服务,会鼓励大量的电话沟通

******

原译文

项目工作手册。在项目的开始阶段

修订译文

工作手册。在项目的开始阶段

******

原译文

它是对项目必须产出的一系列文档进行组织的一种结构。

修订译文

它是强加于项目要产出的文档的一种结构。

******

原译文

包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

修订译文

包括目的、外部规约、接口规约、技术标准、内部规约和行政备忘录。

******

原译文

技术说明几乎是必不可少的

修订译文

技术文字会长期保存下来

******

原译文

还有能追溯到

修订译文

还能追溯到

******

原译文

在合适的章节中

修订译文

在合适的片段中

******

原译文

控制信息发布

修订译文

控制信息的分发

******

原译文

到达所有需要它的人的手中

修订译文

到达所有需要它的人

******

原译文

通过标题列表

修订译文

通过有序的标题列表

******

原译文

维护发布列表

修订译文

维护分发列表

******

原译文

处理机制

修订译文

机制

******

原译文

随着项目规模的扩大

修订译文

随着规模的扩大

******

原译文

非线性趋势增长

修订译文

非线性趋势恶化

******

原译文

若干个线性索引

修订译文

若干个线性序列

******

原译文

散布在多个地点

修订译文

散布在多个物理位置

******

原译文

对结构化工作手册的需要和手册规模上的要求都增加了许多

修订译文

对结构化工作手册的需要增加,而且工作手册的规模也增加了

******

原译文

即在每间办公室中保留一份项目工作手册的备份。

修订译文

即他自己的办公室应该有一份工作手册副本。

******

原译文

如果每次变更都要重新打印所有的文档,那将很难做到

修订译文

如果因为变更,整个文档必须重新键入更改,那很麻烦

******

原译文

活页夹

修订译文

活页簿

******

原译文

计算机文本编辑系统

修订译文

计算机驱动的文本编辑系统

******

原译文

它对实时维护提供了不可思议的帮助。编辑、排版、打印的工作直接在计算机和打印机上完成

修订译文

事实证明,这对于及时维护是非常宝贵的。胶印底板直接在电脑打印机上制作

说明

原文Offset master是印刷行业用语,胶印底板。当时还不存在现在习以为常的计算机排版然后输出到打印机的技术。上文的“计算机驱动”也应该是这个意思。

******

原译文

即便如此,所有接收的人员还是会面临消化

修订译文

然而,所有这些更新页面的接收者都面临消化

说明

all修饰的是pages

******

原译文

当他就问题进行咨询时

修订译文

当他需要查阅时

******

原译文

文档变更有若干个步骤

修订译文

突出显示变更需要其他步骤

******

原译文

竖线标记每行变化的文字

修订译文

竖条标记每个被修改的行

******

原译文

独立的总结性文字,对变更的重要性及批注进行记录

修订译文

独立的变更摘要,列出变更并评论其重要性

******

原译文

这种机制在我们项目中碰到别的问题之前,稳定运行了6个月。工作手册厚达5英尺。

修订译文

我们的项目进行了六个月,遇到了另一个问题。工作手册大约有五英尺厚!

******

原译文

100份手册叠在一起

修订译文

100份副本叠在一起

******

原译文

归入档案的页数

修订译文

需要交错地插在整个文档中的页数

******

原译文

日常维护工作占据了

修订译文

日常维护工作开始占据

******

原译文

在为每个办公室配备了微缩胶片阅读机之后,节约了大量金钱,工作手册的体积减小到原来的十八分之一。更重要的是,对数百页更新工作的帮助—微缩胶片大大地减少了归档问题。

修订译文

即使考虑到为每个办公室购买微缩胶片阅读机的成本,也节省了一百万美元。我们能够为微缩胶片的制作很好地安排周转时间;工作手册从三立方英尺缩小到六分之一立方英尺,最重要的是,更新以一百页为一整块出现,将交错问题减少了一百倍。

说明

漏译一句。原译意思也有偏差。

******

原译文

从管理的角度而言

修订译文

从管理者的角度而言

******

原译文

笨拙的文字归档工作

修订译文

笨拙的纸质页面插入

说明

误译,此处是用纸张和胶片对比。

******

原译文

对于大型项目,我建议把它作为文字工作手册的补充。

修订译文

对于非常大的项目,我会推荐使用它而不是纸质工作手册。


33套UML/SysML+EA/StarUML的建模示范视频-全程字幕(20230217更新)
[架构师强化]6月26-30晚8点分析设计高阶网络公开课(原“剔除伪创新的领域驱动设计”)
6月23-24白天软件需求设计方法学全程实例剖析网课
CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信:umlchina2
继续滑动看下一个

《人月神话》译文修订明细(11)-读者可以对照修改

潘加宇 UMLChina
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存