<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
页码
| 行号
| 2009年1月第1版译文 | 建议的修正
| 备注
|
III | 3 | 事物的本源以及行事之道,玄之又玄的背后终是一个个自圆其说的预言。这确是任何组织发展趋势的终结所在, | 关于世界应该是什么样子或者事情应该怎样去做的神话,最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向, | 我觉得我交稿时的译文更加朴实一点。 |
III | 5 | ,是个致命杀手。 | ,却是个致命杀手。 | 补上“却”,因为这里有转折或者说突出强调技术公司的意思。 |
III | 6 | 切入了这些组织结构中的软肋。 | 深深地切入了组织内部看似无关紧要的东西。 | 我的翻译更加贴近原文。 |
IV | 10 | 关于死亡之旅的栏目 | 关于死亡行军的栏目 | “Death March”全书都统一翻译成为“死亡行军”。 |
IV | 15 | Writting | Writing | 这是一个拼写错误。其实这里没有必要把英文也带出来,包括下面的Beyond Comparison也没必要。 |
V | 16 | 冒牌效应 | 杠杆作用 | 不理解啥叫“冒牌效应”…也许编辑同志的意思是“多米诺骨牌效应”? |
VI | 3 | 他们对彼此正在说的东西都没有一个哪怕是很朦胧的想法。 | 他们对彼此正在说的东西都没有一个哪怕是很朦胧的了解。 | 将“想法”改成“了解”好一点。 |
VII | 3 | 这是一本关于极其实操性的书。 | 这是一本关于最佳实践的书。 | 把“Best Practice”翻译成“极其实操性”就太费解了! |
XI | 7 | 飞猪 | 飞天猪 | “飞猪”翻译得有点生硬。(谢谢台湾的一位读者蔡先生!) |
1
| 4
| 飞猪
| 飞天猪
| 原因同上。
|
2
| 4
| 飞猪
| 飞天猪
| 原因同上。
|
2
| 倒数6行
| 飞猪
| 飞天猪
| 原因同上。
|
4
| 15
| 飞猪
| 飞天猪
| 原因同上。
|
117
| 3
| 飞猪
| 飞天猪
| 原因同上。
|
2 | 26 | 那些“必须有”的功能放在第一个里程碑内,并且标上开发人员的数量和“困难/中等/容易”等级;“最好有”的功能放在第二个里程碑内;“希望有”的功能放在第三个里程碑内。除此之外的所有功能统统不做。 | 那些“必须有”(must-have)的功能放在第一个里程碑内,至于要放哪些、放多少,则取决于开发人员的数量和功能的“困难/中等/容易”等级;“最好有”(like-to-have)的功能放在第二个里程碑内;“希望有”(wish)的功能放在第三个里程碑内;其余功能皆不予考虑。 | 翻译不当。(谢谢台湾的一位读者蔡先生!) |
3 | 11 | 我们否能在合适的时间 | 我们是否能在合适的时间 | 太费解了!为什么编辑同志把“是”字给删了… |
3 | 16 | 并且选择功能实现从困难转向容易, | 并且看着功能实现从困难转向容易, | 这是项目经理观察项目进展情况的一个过程,因此用“看着”。 |
4 | 3 | 而不是帮助你在产品的关键功能上实现降低风险, | 而不是帮助你在产品的关键功能上降低风险, | 编辑同志加了“实现”二字,读起来费解! |
5 | 最后2行 | 获取他们对RAID(Redundant Array of independent Disk,独立冗余磁盘阵列)进行读和写的RDQ, | 获取他们对RAID进行读和写的RDQ, | 括号中的注释完全是误导。关于RAID和RDQ的解释,参见本书最后的术语表,第191页。 |
9 | 19 | 分诊必须最终决定产生。 | 分诊必须最终产生决定。 | 我原来的译稿是“分诊必须最终有决定产生。”编辑同志把“有”字去掉了,费解! |
10 | 6 | 同时把会议的焦点集到了它本该集中的地方。 | 同时把会议的焦点聚集到了它本该聚集的地方。 | 既然是焦点,用“聚集”一词更合适一点。 |
16 | 23 | 然后就是做代码审检。 | 然后就是做代码审查。 | “Inspection”在全书统一译作为“审查”。 |
17 | 倒数12行 | 但没有如实反映情况, | 但你没有如实反映情况, | “你”字漏掉了。 |
23 | 16 | 我非常由喜欢这些开发范例提出来的很多思想和方法。 | 我非常喜欢这些开发范例提出来的很多思想和方法。 | 编辑同志加了个“由”字,但插入的地方有点莫名其妙L |
26 | 16 | 在客户和依赖方或者卖主之间的进行任意形式的沟通 | 在客户和依赖方或者卖主之间进行的各种沟通 | 不通顺。 |
27 | 倒数12行 | 其过程相当得简单。 | 其过程相当地简单。 | 错别字。 |
34 | 2 | 我不能断定谁更恶心:一个是使用“敏捷”方法,并且想知道为什么微软不在全公司范围内采用它,用它解决我们面临的所有麻烦的人;另一个是认为敏捷狂热归根到底是被一些无知的学者鼓吹出来的,它实际上是一种改头换面的愚昧,它让开发者免于任何责任的人。 | 下面的两种人,我无法确定哪种更恶心:一种是使用“敏捷”方法的人,他们甚至想知道为什么微软不在全公司范围内采用它,用它解决我们面临的所有麻烦;而另一种人呢,他们认为对“敏捷”的狂热实际上是被一些无知的学者鼓吹出来的,它虽然改头换面了,但难掩其愚昧的本质,它竟然让开发者免于任何责任。 | 调整表达方式,以便于读者更好地理解。 |
39 | 3 | 这种情况下很最流行使用burn-down图。 | 这种情况下很流行使用burn-down图。 | “最”字是多余的。 |
51 | 倒数3行 | “牛肉在哪里为什么我们要质量”栏目 | “牛肉在哪里?为什么我们要质量”栏目 | “?”漏掉了。 |
55 | 4 | 鲁棒 | 稳健 | 英文原文是“robust”,上下文一致起见,应该译作“稳健”。 |
59 | 倒数6行 | 测试者没有开发者聪明。 | 测试者没有开发者聪明。
| 这句话应该粗体显示。 |
60 | 5 | 公司内的很多人都在通过像在微软准备就绪计划(Readiness At Microsoft Program, RAMP)和测试主管计划(Test Lead Program)之类的启动计划,努力纠正这种不公平。 | 公司内的很多人都在通过微软首创的一些计划,比如“在微软准备就绪计划”(Readiness At Microsoft Program, RAMP)、“测试主管计划” (Test Lead Program)等,力图扭转这种不公正。 | 对专有名词加了引号,便于读者理解。表达方式略微调整了一下。 |
60 | 23 | 借口以推托在整个过程中…的责任。 | 借口以推脱在整个过程中…的责任。 | “推托”纠正为“推脱”,错别字。 |
62 | 24 | 单元测试可以带来更好的实现设计,更可测的代码,更少的的回退、 | 单元测试有助于在代码实现方面做出更好的设计,使得代码的可测试性增强,还带来更少的回退、 | “实现设计”容易引起歧义,因此换一种表达方式。 |
65 | 16 | 突然之间,学着跟技术痴迷者沟通成了 | 突然之间,学着跟技术迷信者沟通成了 | “痴迷”一词是沉迷于某事物的意思,而这里主要指一些傻瓜型的技术新手,因此用“迷信”更恰当一点,与第1段的内容也有呼应。 |
65 | 20 | 因为被排除在本栏目的讨论范围内。 | 因为被排除在了本栏目的讨论范围之外。 | 意思被编辑同志改得不对了L |
71 | 最后一句 | 天上不会掉馅饼! | 比萨饼不会自己走过来! | 我原来的翻译更加朴实一些,而且跟前一段关于比萨饼的例子有呼应。 |
73 | 1 | “你对你的安全放心吗” | “你对你的安全放心吗?” | “?”漏掉了。 |
81 | 3 | 适当的设计产品的受欢迎的可测试性和保障性。 | 适当的设计鼓励增强产品的可测试性和保障性。 | 最初的译稿是“适当的设计欢迎产品的可测试性和保障性”,意思被编辑同志改掉了。 |
81 | 11 | “牛肉在哪里为什么我们要质量” | “牛肉在哪里?为什么我们要质量” | “?”漏掉了。 |
84 | 3 | 也许工程化做软件在某程度上来说是可能的。 | 也许工程化做软件在某种程度上来说是可能的。 | 漏掉了“种”字,读起来不通顺。 |
89 | 9 | 你就不会再不知所措了! | 你再也不会不知所措了! | 原来的表达不够顺畅。 |
92 | 2 | 它是一个完整而关键的客户应用范例的一部分, | 它从属于一个完整而关键的客户应用范例, | 原稿的翻译不符合中文表达习惯。 |
92 | 11 | 并不是计划之内的完整而关键应用范例的一部分。 | 并不从属于计划之内的完整而关键的应用范例。 | 原因同上。 |
100 | 3 | (表内各个名词的排版有误,丢失了层次感)
| (参见本勘误表最下面的表格)
| 编辑同志把原来两行的内容合成成了一行,这样会造成读者无法理解下文的“从表中的左下象限以顺时针方向螺旋向内推进…” |
102 | 24 | (表格排版有误) | (参见本勘误表最下面的表格) | 编辑同志把原来两个表格合并成了一个,不便于理解。 |
112 | 13 | 熟练开发者很少将能达到63级以上的SDE | 熟练开发者很少能够达到63级以上的SDE | 语句不够通顺。 |
120 | 5 | 并且一路驰骋的乐趣吧!
| 尽享一路驰骋的乐趣吧! | 语句不通顺。 |
123 | 5 | ,如此等。 | ,如此等等。 | 编辑同志删掉了一个“等”就不通顺了。 |
152 | 7 | 有简历。 | 有的简历。 | 有“的”更加通顺一点。 |
153 | 13 | 但是,如何去设计合适的问题。 | 但是,哪里去找到这些合适的问题呢? | 修正的版本更加忠实于原文。 |
153 | 28 | 这比应聘者从互联网上获取答案要困难了许多。 | 这还使得应聘者从互联网上获取答案变得困难了许多。 | 编辑同志把原文意思改错了。 |
159 | 2 | 你就能一步一步达到你的职责寄予期望了 | 你就能一步一步达到你的职责寄予你的期望了 | “你的”被删,语句不通顺。 |
168 | 15 | 形像 | 形象 | 编辑同志改出错别字了L |
172 | 22 | 每当关于重组… | (这段开头应该空两格) | 排版有误。 |
178 | 4 | 试都不用试J;” | 试都不用试J” | 多了一个“;” |
181 | 倒数2行 | 我可能还会掀起一场革命! | 我们可能还会掀起一场革命! | 原文是“we”,应该译作“我们”。 |
182 | 通篇 | A公司、B公司 | A公司是指Google,B公司是指Apple | 出版社故意隐去了真实公司的名字。不算什么勘误,可能出版界有什么潜规则吧…… |
182 | 2 | 也许我很无知,但A公司想要跟微软竞争真的很可悲。 | 也许我很无知,但A公司想要跟微软竞争真的很可悲。
| 这句话应该粗体显示。 |
190 | 3 | 贡献者和管理者各自的成果。 | 贡献者和管理者各自的成长路径。 | 原文是“growth paths”,编辑同志把意思改错了。 |
190 | 10 | 编码完成(code complex) | 编码完成(code complete) | 单词拼写错误。 |
191 | 23 | 微软内部管理结构中的第一级多工种管理层管理是人员。 | 微软内部管理结构中的第一级多工种管理层。 | 编辑同志追加了“管理是人员”,但连在一起,不通顺。 |
192 | 6 | 一书对此有详尽的论述。 | 一书对此做了详尽的论述。 | 语句不够通顺。 |
192 | 10 | 分诊(triag) | 分诊(triage) | 单词拼写错误。 |
软件设计的维度
| 外部
| 内部
|
静态
| 项目管理规范书 应用程序编程接口定义 | 开发规范书 测试驱动开发 |
动态
| 用例 | 顺序图 |
水龙头的两个可选的设计矩阵
| 热水开关
| 冷水开关
|
|
| 倾斜杆
| 旋转杆
|
流量
| X | X | 流量
| X |
| |
温度
| X | X | 温度
|
| X |