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

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

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

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

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

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

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

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

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

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

《人月神话》译文修订明细(10)-读者可以对照修改_第1张图片

《人月神话》译文修订如下,读者可以对照自己手上的书修改。

相关阅读

这回真要动刀子-征集《人月神话》中译本的翻译修正>>

第五章 第二系统效应(续)

原译文

OS/360的调度程序是非常出色的,它提供了管理固定批作业的杰出功能

修订译文

调度程序提供了管理固定批作业流的杰出功能

******

原译文

后续的二次系统

修订译文

后续的第二系统

******

原译文

精炼、改进和增强

修订译文

精炼、改进和装饰

******

原译文

是一种主要用于商业应用的系统。但是,它对OS/360的远程任务项、多道程序和永久驻留交互式子系统几乎完全没有影响,也无法提供帮助。

修订译文

主要用于商业应用。OS/360调度程序是很好的,但它几乎完全没有受到OS/360对远程作业入口、多道程序和永久驻留交互子系统的需要的影响

说明

(1)漏译一句。

(2)译反了。uninfluenced by,是没受到***影响,不是没影响***。

******

原译文

OS/360调度程序的设计

修订译文

调度程序的设计

******

原译文

结构师如何避免开发第二个系统所引起的后果,从而避免画蛇添足?是的,虽然他

修订译文

架构师如何避免第二系统效应?显然,他

******

原译文

运用特别的自我约束准则

修订译文

并加以额外的自我约束

******

原译文

过多修饰;根据系统基本理念及目的变更,舍弃一些功能

修订译文

过多修饰,并避免延伸出会因假设和目的的变化而废除的功能

******

原译文

每次改进

修订译文

每次调用

说明

误译,原文invocation。

******

原译文

这些值会在一开始作为决策的向导,在物理实现期间充当指南和对所有人的警示

修订译文

这些值将指导初始决策,并在实施期间作为向导和警示服务于所有人

******

原译文

如何避免开发第二个系统所引起的后果,从而避免画蛇添足?他的决定必须得到至少拥有两个系统以上开发经验结构师的认可。

修订译文

如何避免第二系统效应?他要坚持要求,资深架构师至少有两个系统的经验。

******

第六章 传递消息

原译文

贯彻执行

修订译文

传递消息

******

原译文

假设一个项目经理

修订译文

假设一个经理

******

原译文

许多编程实现人员

修订译文

许多实现人员

******

原译文

1000人开发的系统

修订译文

1000人建造的系统

******

原译文

文档化的规格说明

修订译文

书面规约

******

原译文

书面规格说明

修订译文

书面规约

******

原译文

外部规格说明

修订译文

外部规约

******

原译文

规格说明中难以

修订译文

设计中难以

******

原译文

难以构建实现

修订译文

难以建造

******

原译文

规格说明也不断

修订译文

规约也不断

******

原译文

而其设计和创造是不应该被限制的

修订译文

他的设计自由必须不受约束

******

原译文

体系结构设计人员

修订译文

架构师

******

原译文

为自己描述的任何特性准备一种实现方法

修订译文

随时准备展示他描述的任何特性的实现

******

原译文

试图支配具体的实现过程

修订译文

试图指定实现方式

******

原译文

清晰、完整和准确

修订译文

精确、充实和详细

******

原译文

单独提到某个定义

修订译文

单独参考某个定义

******

原译文

每条说明

修订译文

每个定义

******

原译文

基本要素,所有文字都

修订译文

基本要素,但所有文字都

******

原译文

System/360 Principles of Operation的一致完整性仅来自

修订译文

System/360 Principles of Operation的统一性源于只有

******

原译文

思路是大约10个人的想法

修订译文

想法来自大约10个人

******

原译文

将其结论转换成书面规格说明

修订译文

将其决策转换成书面规约

******

原译文

而且,将定义书写成文字,必须对很多最初并不是非常重要的问题进行判断,并得出结论。

修订译文

对于定义的撰写,有许多小决定是不需要充分辩论的

******

原译文

如何设置返回的条件码

修订译文

如何设置条件码的详细信息

******

原译文

这些看似琐碎的问题

修订译文

这些微小决定在

******

原译文

仔细地规定了对System/360兼容性

修订译文

仔细地描述了对System/360兼容性

******

原译文

或者源于某个模型与其他模型的差异,某个给定模型的复件和其他复件的差异,甚至是工程上的变更引起的复件自身上的差异

修订译文

在这些地方,一种型号的结果可能与另一种型号不同,给定型号的一份副本可能与另一份副本不同,或者在工程变更后,副本甚至可能与自身不同

******

原译文

说明了作者所应

修订译文

说明了编写者所应

******

原译文

手册的作者必须注意到

修订译文

手册的编写者必须努力让

******

原译文

存在的理由和原因

修订译文

存在的理由

******

原译文

倾向完整,差异越明显,填补得越快,但是

修订译文

倾向于完整,漏洞更加显眼,因此可以更快填补。

******

原译文

在表达的精确度上

修订译文

在优雅和精确度上

******

原译文

它们都可以作为表达的标准,

修订译文

这两者的任何一个都可以作为主要标准。

******

原译文

以形式化定义用作派生的论述

修订译文

形式化定义用作辅助

******

原译文

其在书本中有详细的描述

修订译文

并在文献中充分讨论

******

原译文

PL/I的形式化定义

修订译文

PL/I的形式化描述

******

原译文

该概念有很确切的解释

修订译文

该概念有充分的阐述

******

原译文

APL曾用来描述机器

修订译文

APL已经用来描述机器

******

原译文

机器结构的新标注方法

修订译文

机器结构的新表示法

******

原译文

并且在许多机型的应用上得以体现

修订译文

并且用若干机型作为演示

******

原译文

某个设计实现

修订译文

某个实现

说明

后文的“设计实现”都改为“实现”

******

原译文

语法和规则的表达可以不需要具体的设计实现,但是特定的语义和意义通常会通过一段实现该功能的程序来定义

修订译文

语法的描述可以不需要这个,但语义的定义通常是给出一段执行所定义操作的程序

 

你可能感兴趣的:(书籍,软件工程,产品经理,uml,面向对象,架构师)