我最近的作为一个Rails程序员的经历可能并不常见。
我经常被叫去维护一些已经做好的Ruby/Rails项目，在力所能及的地方进行改进和完善。这样，绝大部分我需要接手的项目在我出现前都已经开发完成了。事实上，在我的记忆里，我只参与了一个商业性质的格林菲尔德Ruby项目的开发。其它的，在我看来，都是历史遗物，相当多的程序代码在我之前都已经出品了。(不包括个人和内部项目)。
我知道，我的这种经历在Ruby和Rails程序员中并不常见。由于Ruby/Rails的高产和创业公司为主的用户环境，大多数Ruby爱好者都是在这样刚成立的公司里开发全新的项目。而我的工作更多的是基于最初的开发人员走后留下来的代码。
Rails的让人不堪的小秘密
在受雇写Ruby程序之前，我也接手过一些历史程序，它们有的历史达数十年之久，代码量数十万行之多。你很容易在这么多代码里找出写的很烂的东西；有时候，这种烂代码的数量多的让人惊讶。但是，在Rails开发中，你会发现一个让人不堪忍受的小秘密；在我的职业生涯中，我见过的最乱的、最棘手的、最臭的代码，都是在Ruby _disibledevent=> 事实上，Ruby _disibledevent=>Lone Star Ruby Conf大会上有个极好主题，他提到的巨型项目有4万多行代码。这让我微微一笑，因为我被雇来做的头两个项目分别有5万行和7万行。这看起来不少，但根据行业标准，它们很小。
造成这种现象的原因有不少。Ruby是一种比Java更富有表达性的语言，所以，从某种程度上说，Rails项目，在相同的情况下，总是比那些更讲究的语言显得更小。
而且，Rails程序员很喜欢接受把系统分割成很多很小的、相互联系的小应用。但是经验告诉我们，这种策略是有问题的。
不，我想这导致Rails应用体格较小的最大的原因是，显而易见的：这个框架还很年轻。这个领域里有大量不成熟的产品。一个Rails应用如果有3年的历史，那就可以算是古老了。
我可以很有信心的说，这种情况不会一直持续下去。我们会看到越来越大的程序项目。我不需要鼓起勇气就可以做下面的预言：很多项目将会遭遇像Lisp, Smalltalk, C++, Java等语言曾经遭遇过的相同的架构瓶颈。
你并不特殊
《programming literature from the 80s》这个作品读起来非常的有趣。动态，面向对象的系统引导了从小规模到中等规模的过渡。听起来耳熟，是吧？每一次的革命都会坚称这次是与众不同的，不会造成上次革命后出现的政党纷争和官僚腐败。起初你很容易被这些宣传感染。每个人都很兴奋，热情的去帮助；这时出现的问题还比较小；然而这只是市场的大机器还没有注意到这场运动。
事实上，你要解决的问题也许并不是你想像的那样例外。你思想里的这种拜占庭模式只是远古时代那些使用跟Ruby类似语言的人留下来的遗产。
不要惊慌
放松。我这里要说的并不是告诉你过去的几年只是一场可爱的梦，Ruby实际上一直处在它应有的地位上。Ruby仍然是一种奇妙的语言，它令人惊异的地方就是它在付出微小的约束代价下能轻松的接纳大型系统的设计模式。注入依赖？儿戏。对象委托和组合？小菜一碟。跟你的错觉正好相反，Ruby并不拒绝严谨的设计模式和SOLID编程原则；Ruby能做到的事是让它们更容易的表达出来。事实上，Ruby强大的富于表达的架构风格是让很多人第一眼就喜欢上它的原因。
拜托：请在你告诉我Ruby和Rails不需要任何的约束之前，请跟那些仍然在维护你当初开发的Rails应用的兄弟们聊一聊。
标签： RubyRails
最新评论