扫二维码下载作业帮
1.75亿学生的选择
下载作业帮安装包
扫二维码下载作业帮
1.75亿学生的选择
英语翻译这是著名软件开发专家Martin Fowler曾这样评价JUnit的一个评语.我想请教一下这个句子如何准确翻译.有翻译是这样的 “在软件开发领域中,从未有过如此众多的代码行从如此少量的代码行中得到了如此巨大的益处.” 也有这样的 “软件开发领域中此前从未有过这样的事情：很少几行代码对大量的代码起了重要的作用”.请详细、按结构翻译一下,太多个so搞到我头都大了.我知道be owed to是归功于的意思。可否这样断句？：be（so much） owed (by so many) to。那括号中的都代表什么？
扫二维码下载作业帮
1.75亿学生的选择
有一个必须知道的知识：倒装句形式应该是这样的：[Never+系动词+主语]或[Never did 主语+动词原型]首先把修饰结构全部拿走.【Never was [so much] owed to so few lines of code.】注意上面提到的倒装句结构.不要忘了much除了副词还是代词.这句话的真正主语是[so much].否则句子就没有了主语.好,现在是一个倒装,还是一个被动句.下面开始分析.(注意是owe to,归因于, 而不是own to承认, )首先要知道be owed to到底是怎么回事.这个结构显然是由主动态演化的,要知道主动形式的真正结构是这样的：【owe sth. to sb/sth】这个真正的宾语是永远都不能省略的.比如：He owes his success to luck. 他认为他的成功是靠运气反过来说,His success is owed (by him) to luck .回过头来看我们这句：So much was owed (by so many) to few lines of code. 是不是一目了然?于是：【核心】【我们主动句是】【[So many] owed [so much] to [so few lines of code]】解释：
对于你给的译文,不知道是什么人翻译的,也不知道上下文是什么样子的.
其实我不懂为什么so many要指代码.从后面的lines of code讲,code是一个不可数名词,怎么可能是so many.但是如果是指代so many lines of code,是不是过于牵强呢.
虽然后面紧接着出现了so few lines...但是这可不是可省略的.在非并列结构的时候,省略的必须是后面出现的.最多是可以说owed by so many lines of code to so few ones.
而且即便是这样,也是不合理的,为什么呢,因为owe这个动作是一个逻辑思考的动作,它一定应该是人发出的动作.即使受益的是代码,也应该是“人”来把代码得到的益处归因于那个东西.所以我认为你给的两句翻译估计都不是什么权威的翻译.甚至是错误的翻译.我认为,这里so many与so much都是虚指.
[so many]指的是so many lines of code也好,so many people也好,甚至是so many industries, so many acchievments 等,总之他们是得到了"so much"的个体们.
而[so much]这里更是一个比较妥帖的一个指代,它指代了一切,就是一切可以将之归功于[so few lines...]的事情,比如 so much development, so much benefit, so much convience 等等.
其实这个用法在中文中有着几乎一模一样的说法,就是类似于“有太多的人太多的事”“从中得到了太多太多”.这里主语、宾语、间接宾语,连续用了三个so, 算得上事一种小排比的修辞,很好的用法.由【[So many] owed [so much] to [so few lines of code]】下面我们看看原句是怎么得到的.【1】 将其改为被动句以强调so much,So much was owed (by so many) to so few lines of code.【2】将其改为否定句以强调其开辟性意义,否定句把系动词was放在主语的前面.Never was so much owed by so many to so few lines of code.【3】加上状语.Never (in the field of software development) was so much owed by so many to so few lines of code.看看是不是和原句一模一样的呢?嘻嘻.【分析完毕.】翻译：首先知道了,在软件开发领域中,从未有so much被so many归功于so few lines of code.至于语言组织,那要看语文水平了.【服从原文的翻译：】【在软件开发领域中,从来未曾有过如此多的地方从如此短的代码中收获了如此多的东西】.（或这样短的代码能让这么多地方都这般深受其益）【简洁的翻译：】【仅仅几行代码就带来了如此广泛,如此巨大的影响,在软件开发领域是前所未有的.】
为您推荐：
其他类似问题
前后的意思差不多后者更益理解吧
永远不要涉足于微软行业，因为这个行业快速的发展是由很少知道里面秘密的人推动的！
其实，你把这个倒装句打成原型就稍微好理解些了：In the field of software development, so many never owed so much to so few lines of code.own to是个短语，意思是承认（属实）比如：He owned to a feeling of guilt. 他承认有歉疚感。那放在这个...
我觉得这个句子可以这么断句：Never in the field of software development /was/ so much owed by so many/ to so few lines of code。意思是在软件开发领域，从未有过如此多的人从这么少的几行代码中获得如此大的益处。我觉得这里的so many 翻译做人，而不是代码可能会更合适一些，不过主要还是看这个领域...
扫描下载二维码966,690 四月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
Martin Fowler
加入InfoQ时间
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。赞助商链接
Martin fowler几年前曾经非常推崇ORM(对象/关系数据库映射框架)，特别是Hibernate和Ruby的Active Record，现在他面对大家越来越多对ORM责难和怀疑。他写了这篇新的文章：，下面大概谈谈他这篇文章大意。首先，MF为ORM带来的复杂性做了辩解，对象和关系数据库存在天然阻抗，试图调和总是带来复杂性。他也认为：The object/relational mapping problem is hard，试图在对象和关系数据库之间进行映射是很难的，因为你需要处理两种不同角度视图中的数据，一个是关系数据库中，还有一个是内存中in-memory，这两者常常是由ORM实现，这里一点和对象没有关系，准确地说，ORM实际是在进行内存(in-memeory)和关系数据库之间映射，内存数据结构比关系模型要更灵活，大多数人更愿意使用这种内存数据结构，然后将其再保存持久到数据库中。这种映射要比我们想象复杂得多，因为你一旦在内存改变数据结构，就必须映射同步到另外一边，如果有多个操作同时并行修改数据库就更复杂，ORM得处理这种并发，这种情况下你不能依赖事务机制，因为当你摆弄内存中数据，你是不能hold住事务的(通常通过数据库锁hold住)。那么有没有ORM的替代呢？MF提出两个解决方案：MF认为Hibernate 和 Active Record 已经是一个膨胀化软件，他看到很多人开始做自己系统的ORM，这是非常厉害的，但是他们没有意识到已经掉入泥潭，MF认为对象和关系数据库的映射如同计算机科学中的越战。虽然很多ORM框架如 iBatis, Hibernate, 和 Active Record做了很多努力解决了很多问题，但是关键问题还是存在，ORM能够解决80%-90%的问题，但是剩余的问题就必须理解ORM和关系数据库内部工作机制才能解决。MF认为这实际就是正确使用ORM的方式，他以Ruby中Active Record创造者David Heinemeier Hansson的话为例子，ORM帮助你处理掉了大部分无聊垃圾代码，但也提供了一个管道和沙井，让你直接处理SQL语句。但是人们常常抱怨，为了使自己的对象模型更适合ORM，屈就ORM，只能变得更加具有关系化，MF认为这是使用关系数据库的必然结果，你要买使你的内存模型更加关系化，要么复杂化你的映射代码，为了简化你的对象和关系数据库映射，你最好哦让你的领域模型更加具有关系化，但是并不意味着你得按关系模型设计领域模型。ORM是复杂的，因为它得处理双向映射，如果只有单向映射，问题复杂性也许就会解决，前提是你感觉SQL不复杂，这就是CQRS(读写分离)。
MF提出避免ORM这些复杂性的两个替代解决方案：1.使用内存关系模型，也就是直接使用SQL。2.干脆不使用关系数据库，直接使用NoSQL。个人认为这两种方案比较极端，还是CQRS方案更好，实际可以通过内存中对象化的领域模型来屏蔽掉SQL或NOSQL，无论是SQL或NoSQL，都是领域对象的持久化，当然批量查询读取专门走另外一条线，结合NOSQL+Hadoop可以实现大数据分析。MF提出这两种解决方案，其实还是不想否定ORM作用，将ORM复杂性归结为关系模型，其实纯粹的关系模式是很干净简单的，复杂就在于你把对象和关系搞在一起。
Twitter中有人认为：devs abused ORM, using it as flat data access layer. Hibernate's overkill if you're not letting it handle relationships开发者喜欢将ORM作为扁平数据访问层，(扁平数据是非结构化，非关系化)，你如果不让Hibernate处理关系，实际它就没有什么用处。[该贴被banq于 12:03修改过]我2009年观点：[该贴被banq于 09:04修改过]
ORM确实没什么用了。但我们不能否认业务对象的关联，在去年我采取了一种新的查询方式：不在数据库中关联（即坚决不使用join），而在内存中关联（可使用in）。因为这样导致查询缓存命中率奇高，所以系统性能大幅度提升。
我认为让ORM负责简单的CUD就好了，现在.NET有没有成熟的CQRS框架？
赞助商链接
赞助商链接
最佳分辨率
OpenSource
Code & 2002-20大二那会儿在QQ群里听到有“设计模式”、“测试驱动开发”等软件设计及软件工程类的知识字&#30524;，出于好奇，我还是很认真的去Google了相关词汇的解释。可能也是了解了一些关于设计类的话题，自己也开始对“写代码”这活，有一点往“艺术性”方向理解的意识，而不是ACM的题海战，或是CMD里那很有频率闪动的光标而已。
读完了马丁花大神的《Patterns of Enterprise Application Architecture》后，又读了他的《Refactoring》。我好像有点墙头草的意思，那会儿天天脑子里在想怎么去运用这些大神的利器，哪怕是只写了两个豪不相干的类，也要想那么几分钟，看看这俩货有没有缊藏着什么深厚的模式～哈哈，反正当时是有点过头～后来的代码时间里，自己也在慢慢总结复习了之前看过的那些书本，然后我开始去用《测试驱动开发（Tdd）》里的“一步一个脚印”的思路，再去结合《Refactoring》里提到的“重构：即在保持现有代码功能不变的情况下，改善现有代码。”慢慢的，我好像有点把住什么时候应该去做优化的时机了。还是基于原来老前辈们总结的几个点....
详细请见：& 来批斗我吧～
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2600次
排名：千里之外
(1)(1)(1)(1)(3)Martin Fowler
Martin Fowler
发布时间： 18:53:50
编辑：www.fx114.net
本篇文章主要介绍了"Martin Fowler"，主要涉及到Martin Fowler方面的内容，对于Martin Fowler感兴趣的同学可以参考一下。
【背景介绍】　　现任ThoughtWorks公司首席科学家的Martin Fowler先生是当今世界软件开发领域最具影响力的五位大师之一。在数十年的职业生涯中，他大力倡导业内最先进的软件开发技术，如统一建模语言UML（Unified Modeling Language）、极限编程XP（Extreme Programming)、重构 (Refactoring) 与分析模式 (Analysis Patterns) 等。在为倡导改革的大型公司们提供解决方案的同时，他进一步完善了这些技术。这些大公司包括花旗银行、埃森哲咨询公司 (Accenture) 、Sterling Software 及戴姆勒－克莱斯勒汽车公司等。
　　Fowler先生经常在许多国际软件开发会议上发表演讲，并曾担任XP 2005大会的主席。他是IEEE 软件杂志的专栏作家，也是敏捷联盟（Agile Alliance）的创建人及《敏捷软件开发宣言》（Manifesto for Agile Software Development）的作者之一。ThoughtWorks公司为Fowler先生办有一个非常流行的网站：，他常在那里撰写文章和博客。
　　Fowler先生的著作精品包括《重构－改善既有代码的设计》(Refactoring: Improving the Design of Existing Code) ，荣获多个奖项的《UML精粹：标准对象建模语言简明指南》(UML Distilled：A Brief Guide to the Standard Object Modeling)? 第二版、《分析模式：可重用的对象模型》(Analysis Patterns：Reusable Object Models) 、《规划极限编程》(Planning Extreme Programming) 和《企业应用架构模式》(Patterns of Enterprise Application Architecture) 等。他还为 Addison-Wesley 出版公司编辑了系列著作。
　　ThoughtWorks公司成立至今 14 年，目前已发展到 800 多名员工。连续4年被美国《Inc. Magazine》杂志评为美国发展最快的 500 家公司之一。总部设在美国芝加哥，在美国的其它一些城市（旧金山、纽约、纳什维尔）以及英国（伦敦）、加拿大（卡尔加里）、印度（班加罗尔）、澳大利亚（墨尔本、布里斯班、悉尼）都有分公司，2004年以后在中国的西安和北京也成立了分公司。业务范围涉猎极广，包括提供咨询和培训（1 人，历时若干个星期）、集中式团队开发（4 - 6 人，历时若干个月），乃至复杂软件实现过程（60 - 80 人，历时 2-4 年）。&
一、不得利用本站危害国家安全、泄露国家秘密，不得侵犯国家社会集体的和公民的合法权益，不得利用本站制作、复制和传播不法有害信息！
二、互相尊重，对自己的言论和行为负责。
本文标题：
本页链接：