Ruby on Rails 代码质量检查清单

据我经验，Ruby和Ruby on Rails一直是最难真正掌握的语言/框架组合之一。对于C、C++和Java程序员而言，Ruby有着非常不同（很不好）的OO设计方法，Rails有太多需要理解和记忆的主张。依我的水平，我已经花了不少时间 ------ 我坚信还有很长的路要走 -------我爱它，并坚持到底。

我对Ruby on Rails人数保持增长私下表示过怀疑，仍然有很多开发者沉湎于Java形式的OO思想，这也是很多人正在学的；这是非常好。同时，它也是坏事，因为垃圾代码源于其他的垃圾代码，在发布或被其他人查看的时候。

ThriveSmart雇佣了更多的开发者------他们不都是Ruby或Ruby on Rails专家------有必要确保代码和设计模式在跨项目中保持一个较高的质量水准。My good friend Dan和我整理了这个清单，便于小组应用到他们的每个项目里。

这是一个不断更新的清单，下面只是临时的片段。

以下略

解释

清单上的每一条对于经验丰富的Ruby on Rails开发者比较熟悉、不值一提了 ------但是对新手而言，还需一些解释。往下看：

(1)每个controller action 仅仅调用一个model方法而不是初始化的find或new。必要时，自定义一些 .net 或 .update的方法.

胖模型、瘦控制器是Rails编码最提倡的方法论------但是它太开放，以至于很难按照我的方式说明。通常，你把所有的逻辑堆在了model里，因此你的controler看起来和script/generate产生的controller一模一样------除了自定义方法，你只是把通常的.new 和 .update_attributes方法按相同方式处理。举一个简单的例子，有一个额外的逻辑，属性被一个特定的user更新：@foo.update_attributes_by_user(params[:foo], current_user)。

额外逻辑应该放在controller、而非model中仅仅当它要渲染不同的action或做出不同的跳转。

（2）仅仅一个或两个实例变量在controller或view之间共享。

实例变量hell很容易出现在Rails里------当controller和view共享很多实例变量时。它潜在地会损害性能，由于你会重复调用一些未知的关联。相反，你的controller应该仅仅控制一个实例变量------或许还有一个current_user。这样，所有的关联均可以“按需”调用，并在一个地方成为实例变量缓存。

该方法同样适用于片段缓存，因为在实际载入关联之前，你可以检查一下view中的缓存。

例如，你的Blog controller不必建立实例变量@post和@related_posts，仅仅建立一个方法，@post会给出Post模型中的related_posts 方法，因此你只需在view层调用@post.related_posts。

（3）所有的model和变量名要简明（对新手）、尽可能短、但不要使用英文缩写。

命名比较难。特别对于那些专心一个应用程序的开发人员------当你头脑中载入整个应用程序上下文时，它或许明显，但对于后来的你或别人就不太明显啦。

Ruby和Ruby on Rails其中伟大之处在于命名简明扼要、可读性强，哪怕对新人。不要破坏它的强大力量！

如果你不能马上想到一个灵巧的、清晰的、短名字，先编码你的方法，然后试着丢掉刚才的代码环境。在一天结束的时候，放一个TODO进去、重新命名变量或方法名称。

 

（以下待翻译） 

 

原文地址： http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist

评论

2 楼 aihua 2009-04-27  

继续哦~
期待。

1 楼 Anddy 2008-12-02  

谢谢翻译~~~一定很多人会感激你的。。。