您的位置：首页 > 编程语言

《代码之道》勘误表(2008.12.31更新)

2008-12-21 18:42 204 查看

页码	行号	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

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航