Helper Antipatterns

Helper AntiPatterns

Helper (輔助方法)的存在目的是用來輔助整理 View 中內嵌的複雜 Ruby 程式碼。設計得當的 Helper 可以加速專案的開發,以及增進程式的可讀性。然而,設計不好的 Helper 卻可能造成嚴重的反效果。

以下列舉常見的幾種糟糕的 Helper 設計模式:

1. 矯往過正:用 Helper 作 partial 該做的事

開發者以為 partial 效率是低下的,刻意不使用 partial,而改用 Helper 完成所有的動作:將需要重複使用的 HTML 通通寫成了 Ruby code,串接成 HTML:
def show_index_block(block_name, post, is_show_game)

block_title = content_tag(:h3, block_name)
section_header = content_tag(:div, block_title, :class => “section-header”)

game_name = is_show_game ? “【 #{post.games.first.name} 】” : “”
title = content_tag(:h4, link_to(“#{game_name} #{post.title}”, post_path(post)))
image = content_tag(:div, render_post_image(post), :class => “thumbnail”)
content = content_tag(:p, truncate( post.content, :length => 100))
section_content = content_tag(:div, “#{title}#{image}#{content}”, :class => “section-content”)

section_footer = content_tag(:div, link_to(“閱讀全文”, post_path(post)), :class => “section-footer”)

return content_tag(:div, “#{section_header}#{section_content}#{section_footer}” , :class => “article-teaser”)
end
 Helper 的作用只是協助整理 HTML 中的邏輯程式碼。若有大片 HTML 需要重複使用,應當需要利用 partial 機制進行 HTML 的重複利用。這樣的寫法,非但效率低下(可以用 HTML 產生,卻使用 Ruby 呼叫 Tag Helper,且製造大量 Ruby Object),且嚴重降低程式的可讀性,其他維護者將難以對這樣的 DOM 進行後續的維護翻修。

 

 
2. 容易混淆:在 Helper 裡面穿插 HTML tag

這也是另外一個矯枉過正的例子,不過方向剛好相反:「因為覺得使用 Ruby code 產生 HTML tag 可能浪費效能,而直接插入 HTML 在 Helper 裡面與 Ruby Code 混雜。」也造成了專案維護上的困難:因為 Ruby 中的字串是使用雙引號”,而 HTML 也是使用雙引號”,,所以就必須特別加入 ” 跳脫,否則就可能造成 syntax error。
錯誤
def post_tags_tag(post, opts = {})
# ….
raw tags.collect { |tag| “#{tag}” }.join(“, “)
end
大量的 ” 混雜在程式碼裡面,嚴重造成程式的可閱讀性,而且發生 syntax error 時難以 debug。
def post_tags_tag(post, opts = {})
# ….
raw tags.collect { |tag| “#{tag}” }.join(“, “)
end
即便換成 ‘ 單引號,狀況並沒有好上多少。
def post_tags_tag(post, opts = {})
# …
raw tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(“, “)
end
正確的作法應該是妥善使用 Rails 內建的 Helper,使 Helper 裡面維持著都是 Ruby code 的狀態,並且具有高可讀性。

3. 強耦合:把 CSS 應該做的事綁在 Ruby Helper 上。

錯誤
def red_alert(message)
return content_tag(:span,message, :style => “font-color: red;”)
end

def green_notice(message)
return content_tag(:span,message, :style => “font-color: green;”)
end
開發者不熟悉 unobtrusive 的設計手法,直接就把 design 就綁上了 Ruby Helper。將來設計上若需要變更時,難以修改或擴充。
正確
def stickies(message, message_type)
content_tag(:span,message, :class => message_type.to_sym)
end

Please Login!!
樣式應該由 CSS 決定,使用 CSS class 控制,而非強行綁在 Helper 上。
4. 重複發明輪子

Rails 已內建許多實用 Helper,開發者卻以較糟的方式重造輪子。在此舉幾個比較經典的案例:

cycle
如何設計 table 的雙色列效果?

<% count = 0 > <table> <% @items.each do |item| %> <% if count % 2 == 0 %> <% css_class = “even “%> <% else %> <% css_class = “odd” %> <% end %> <tr class=”<%= css_class %>”> <td>item</td> </tr> <% count += 1%> <% end %> </table>

一般的想法會是使用兩種不同 CSS class : even 與 odd,著上不同的顏色。

<table> <% @items.each_with_index do |item, count| %> <% if count % 2 == 0 %> <% css_class = “even “%> <% else %> <% css_class = “odd” %> <% end %> <tr class=”<%= css_class %>”> <td>item</td> </tr> <% count += 1%> <% end %> </table>

這是一般粗心者會犯的錯誤。實際上 Ruby 的 Array 內建 each_with_index,不需另外宣告一個 count。

<table> <% @items.each_with_index do |item, count| %> <% if count % 2 == 0 %> <% css_class = “even “%> <% else %> <% css_class = “odd” %> <% end %> <tr class=”<%= css_class %>”> <td>item</td> </tr> <% count += 1%> <% end %> </table>

但其實還有更簡便的方法:Rails 內建了 cycle 這個 Helper。所以只要這樣寫就好了…

<table> <% @items.each do |item| %> <trodd”, “even”) %>”> <td>item</td> </tr> <% end %> </table>

常用你可能不知道的 Helper

限於篇幅,直接介紹幾個因為使用機率高,所以很容易被重造輪子的 Helper。開發者會寫出的相關 AntiPattern 部分就跳過了。

#TODO: examples

5. Tell, dont ask

這也是在 View 中會常出現的問題,直接違反了 Law of Demeter 原則,而造成了效能問題。十之八九某個 View 緩慢無比,最後抓出來背後幾乎都是這樣的原因。

不少開發者會設計出這樣的 helper:

 
def post_tags_tag(post, opts = {})
tags = post.tags
tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(“, “)
end

這種寫法會造成在 View 中,執行迴圈時,造成不必要的大量 query (n+1),以及在 View 中製造不確定數量的大量物件。View 不僅效率低落也無法被 optimized。
def post_tags_tag(post, tags, opts = {})
tags.collect { |tag| link_to(tag,posts_path(:tag => tag)) }.join(“, “)
end

def index
@posts = Post.recent.includes(:tags)
end
正確的方法是使用 Tell, dont ask 原則,主動告知會使用的物件,而非讓 Helper 去猜。並配合 ActiveRecord 的 includes 減少不必要的 query( includes 可以製造 join query ,一次把需要的 posts 和 tags 撈出來)。

且在 controller query 有 object cache 效果,在 view 中則無。

小結

Helper 是 Rails Developer 時常在接觸的工具。但可惜的是,多數開發者卻無法將此利器使得稱手,反而造成了更多問題。在我所曾經參與的幾十個 Rails 專案中,很多設計和效能問題幾乎都是因為寫的不好的 View / Helper 中的 slow query 或伴隨產生的大量 object 所造成的 memory bloat 導致的。但參與專案的開發者並沒有那麼多的經驗,能夠抓出確切的病因,卻都將矛頭直接是 Rails 的效能問題,或者是沒打上 Cache 的關係。這樣的說法只是把問題掩蓋起來治標,而非治本。

下次若有遇到 performance issue,請先往 View 中瞧看看是不是裡面出現了問題。也許你很快就可以找到解答。

Posted by xdite Jan 12th, 2012