你的代码是我的地狱

发表于:2013-03-30来源:外刊IT评论作者:不详点击数: 标签:代码
你的代码是我的地狱 我最近的作为一个Rails程序员的经历可能并不常见。 我经常被叫去维护一些已经做好的Ruby/Rails项目,在力所能及的地方进行改进和完善。这样,绝大部分我需要接手的项目在我出现前都已经开发完成了。

  我最近的作为一个Rails程序员的经历可能并不常见。

  我经常被叫去维护一些已经做好的Ruby/Rails项目,在力所能及的地方进行改进和完善。这样,绝大部分我需要接手的项目在我出现前都已经开发完成了。事实上,在我的记忆里,我只参与了一个商业性质的格林菲尔德Ruby项目的开发。其它的,在我看来,都是“历史遗物“,相当多的程序代码在我之前都已经出品了。(不包括个人和内部项目)。

  我知道,我的这种经历在Ruby和Rails程序员中并不常见。由于Ruby/Rails的高产和创业公司为主的用户环境,大多数Ruby爱好者都是在这样刚成立的公司里开发全新的项目。而我的工作更多的是基于最初的开发人员走后留下来的代码。

  Rails的让人不堪的小秘密

  在受雇写Ruby程序之前,我也接手过一些历史程序,它们有的历史达数十年之久,代码量数十万行之多。你很容易在这么多代码里找出写的很烂的东西;有时候,这种烂代码的数量多的让人惊讶。

  但是,在Rails开发中,你会发现一个让人不堪忍受的小秘密;在我的职业生涯中,我见过的最乱的、最棘手的、最臭的代码,都是在Ruby on Rails项目里找到的。我所见过的那些Rails项目,它们两年下来积累的技术债务和废弃物,跟一个10年之久的C/C++程序相比,会让你觉得后者更干净和优雅。我说的并不是某个项目。我看到这种情况到处都是。

  有时候我会想,这也显示了这种语言的强大之处。如果在一个Rails应用里有500个错误,你可以不停的往里面添加代码、再添加代码、点击“reload“,一直到它好用为止。从来都不需要写测试或重构代码。在很多语言和框架里,这种”补到它不漏为止“的开发方式显而易见是行不通的。但Ruby on Rails却提供了让你这样做的平台。

  不幸的是,作为它的直接后果,众多我要处理的项目都可以被看作是一种应急产品。从某种角度来看,这种图省事的做法的后果还是由开发团队来承担,你这样做一天把它解决了,可引出的相关问题和不可预料的副作用,你花2周都解决不掉。

  题外话:经常的,最初的开发人员会在完成开发后转移到新的项目上。同时会有新员工接手这些代码。管理部门会抱怨,为什么这新接手的团队修改问题时没有老团队迅速呢?而新团队遇到的问题是,在他们能给这些遗留的代码上添加新功能前,他们需要让这些代码具有更高的测试覆盖率,有可能还需要把它们分离成更小的模块;在商业层面,一个永久不变的声音是:测试和重构就是拖延工期。看来这原创团队都是比较明智的。

  好了,牢骚发完了。

  Rails的情况更为特殊!

  Rails程序员有时候会显得很傲慢和固执。我不清楚这个判断的可信度;我并没有看到太多的人是这样,但也许我跟这个社区太接近了,也许我本身也是傲慢和固执的。

  而我发现的却是一种“Rails例外主义“。还记得第一次互联网繁荣的时期吗,当时有几个经济学家跳出来说”不会的,这次不同,互联网改变了游戏规则,市场会一直走高、走高“,本质上我感觉很相似,有些人相信,Ruby on Rails开发是某种不同的东西,不需要跟其它类型的软件项目一样。

  这有一些例子,让你明白我究竟在说什么:

  “设计模式是Java上的东西。Ruby里只管写你的代码就是了。“

  “Ruby里抛出的警告都是无聊的,禁止掉就行了。“

  “的确没有单元测试,而且对象隔离做起来了很难,没有人这样做。“

  “到处打补丁对于其它语言来说是不赞成的,但Ruby没问题。目前还没有出现问题。”

  “像Demeter 定律这样的东西在Ruby里并不是这么重要。“

  “把方法分成私有和公有,这是变态控制,Ruby里不需要这样做“

  “Java代码里才会有代码异味(code smell)。“

  “只有在大项目里才会有这样的问题“(暗示这个项目永远不会变大)

  我还看到了很多项目和子系统例外主义者:“我知道一个类不应该搞的太大,但是对这个类是有意义的,它是为了把所有的东西放到一个地方“。

  欢迎来到小人国

  事实上,Ruby on Rails项目确实有一点很例外:都是小项目。上周在James Gray在Lone Star Ruby Conf大会上有个极好主题,他提到的“巨型“项目有4万多行代码。这让我微微一笑,因为我被雇来做的头两个项目分别有5万行和7万行。这看起来不少,但根据行业标准,它们很小。

  造成这种现象的原因有不少。Ruby是一种比Java更富有表达性的语言,所以,从某种程度上说,Rails项目,在相同的情况下,总是比那些更讲究的语言显得更小。

  而且,Rails程序员很喜欢接受把系统分割成很多很小的、相互联系的小应用。但是经验告诉我们,这种策略是有问题的。

  不,我想这导致Rails应用体格较小的最大的原因是,显而易见的:这个框架还很年轻。这个领域里有大量不成熟的产品。一个Rails应用如果有3年的历史,那就可以算是古老了。

  我可以很有信心的说,这种情况不会一直持续下去。我们会看到越来越大的程序项目。我不需要鼓起勇气就可以做下面的预言:很多项目将于遭遇想Lisp,Smalltalk,C++,Java等语言曾经遭遇过的相同的架构瓶颈。

  你并不特殊

  《programming literature from the 80s》这个作品读起来非常的有趣。动态,面向对象的系统引导了从“小规模“到”中等规模“的过度。听起来耳熟,是吧?

  每一次的革命都会坚称这次是与众不同的,不会造成上次革命后出现的政党纷争和官僚腐败。起初你很容易被这些宣传感染。每个人都很兴奋,热情的去帮助;这时出现的问题还比较小;然而这只是市场的大机器还没有注意到这场运动。

  事实上,你要解决的问题也许并不是你想像的那样例外。你思想里的这种拜占庭模式只是远古时代那些使用跟Ruby类似语言的人留下来的遗产。

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)