大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Java、Ruby和持续负担
作者 Scott Delap 译者 郭晓刚 发布于 2007年10月9日
最近在ActiveRecord与Hibernate之间的争论当中，Google的Bob Lee用了“持续负担（continuous tax）”这个词，来形容使用Ruby这样的动态类型语言相对于Java这类静态类型语言的优缺点：
一般来说Java的学习曲线比Ruby要陡峭，特别是如果你考虑到泛型和学习最大限度地发挥语言的能力。Java的类型系统对长期的可维护性和可用性有好处。而利用Ruby你可以抄捷径省掉这些步骤，更快地顺利得到结果，但你也要付出持续负担（continuous tax）。
Google员工以及TestNG的作者Cedric Beust也注意到了这个词：
“持续负担”这个词是说，当你需要维护或使用用Ruby或Python这样的语言编写的API，你能够得到的信息很少，即便你通过查看测试代码理解了API的含义（有谁这样做过吗？），这种理解和知识也是短暂的，一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程……
Brian Doll将讨论引向了测试与“持续负担”的关系，Beust对此回应说：
实际上我并不认为编写测试属于我先前提到的持续负担。虽然我同意用静态类型语言的时候比用动态类型语言通常要少写一些测试，但是代码行数或者测试数量的差异还没有大到能够真正影响开发过程。持续负担是由代码明确性方面的损失引起的，动态语言写出来的代码通常要蒙受这种损失。虽然看起来无关痛痒，实际上丢失类型信息对代码的可维护性和可读性有可怕的影响，因为你看不出传给方法的一个对象到底是什么类型，更糟的是使得连最简单的自动重构也没法应用，比如重命名一个公开方法。
Dion Almaer根据他自己使用动态和静态类型语言的经验进行了反击：
- 动态语言编写的项目代码较少，团队维护起来更容易。
- 动态语言项目的团队较小，因此我们更容易维护（我们可以用更少的人做更多的事）。
- Java项目通常是过度设计的（不是Java本身的问题，而是传染了社区中很大一部分人的流行病）。
查看英文原文：Java, Ruby, and the Continuous Tax
译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。
连续累进税
发表人
Wang Dali
发表于
Re: 连续累进税
发表人
Guo Xiaogang
发表于
不敢认同
发表人
zane dennis
发表于
Re: 不敢认同
发表人
Zaoldyeck Solomon
发表于
问题在于设计
发表人
wang edge
发表于
使用静态语言的人总是忧虑这个问题
发表人
田 乐
发表于
-
连续累进税率不是中国的个人所得税方式，Infoq中国也不应当成为推出新词的消息队列，整点大家熟悉的可以理解的术语吧
或者注释些相关的背景知识让中国的开发者明白超额累进税率和连续累进税率的分别 -
这种理解和知识也是短暂的，一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程……
---------------------------
难道java不一样？一年之后你同样要重新去理解，这个不成为理由。类型信息是很多情况下并没有想象中的重要。 -
确实像dennis说的一样，我国现在开发绝大多数并不注意类型信息的使用，所以动态语言这点上也不一定比Java损失更大。不过不知道国外这点做得怎么样。不过我感觉这至少是一种理念，我们应该时刻朝着方便和可复用性好的方向努力。
-
正如Dion Almaer所说，“Java项目通常是过度设计的（不是Java本身的问题，而是传染了社区中很大一部分人的流行病）。”
所谓的“一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程……”，对于一个过度设计的的Java系统同样适用 -
这里并不是continuous progressive tax rate，不知道“连续累进税率”从何而来。能不能请你说说你的理解？
-
使用静态语言的人总是担忧项目的维护问题，担心项目规模变大或者时间很久以后代码会因为退化而变得难以维护。其实静态语言的编译起检查的确能带来一些作用，但不是决定性的。更好的方法还是通过不断的重构和测试，尤其是测试。
考虑到测试的代码，动态语言与静态语言的代码量差距会缩小一些。
6 条回复
关注此讨论 回复