《Rapid Development with Rails》- 不用老想着Rails的CRUD，看看它的真正优点

《Rapid Development with Rails》-- 不要老想着Rails的CRUD，看看它的真正优点

#

# 原作者：xdite

# 原文地址：?http://blog.xdite.net/?p=2124

#

?

Rapid Development with Rails ( OSDC 演講）

?

?

?

這是我在?OSDC 2011?的前言草稿。本來是打算週六才打算放出來的，不過目前對岸正在 Twitter 上演 Rails 與 PHP 之爭（詳情請看?@robbinfan?與?@fenng?的大戰），看了手癢。 想了一下，還是把當天的這前十分鐘講稿先放出來好了…

我的主題是如何善用 Rails 特性達到 Rapid Development。這場 talk 不會有太多的 code，一些觀念上的闡釋和搭配的架構介紹會講比較多。時間是 3/26（六）的下午 2:00 在中研院

====

簡單自我介紹一下，我是 xdite，在?T 客邦工作。我目前的角色是 Lead Developer 與 Manager。中間是有去「出國深造」一陣子 ….不過目前回來了 XD

我寫 Rails 大約有快四年的時間，之前待過和多、PIXNET?與?HTC。

講題概念 ( 澄清關於對 Rails 的一些錯誤認知）

大概講一下這次會講這個主題的原因：Ruby on Rails 一直以來是一個非常優秀的網頁框架。應該是有始以來最棒的網頁框架，開發者不僅可以從中跟上世界頂尖開發者的研究進度，滿足自己的技術癮之外，又可以穩穩的兼顧快速的商業需求。很可惜因為種種因素，讓世人對人一直對它停留在非常糟糕的印象（「市場上找不到開發者」且「只適合滿足技術狂人癮頭」的「效率糟糕」「不穩定」框架）。

Rails 對於生意與開發上的幫助，絕非只有「Rapid Development」可言。Rails 如果如同大家所說的，只是這種糟糕的玩具，相信也活不到今天，也絕不會有越來越多的開發者、商業網站投入採用。如果各位正在或曾經開發網站，深入把玩過幾個框架，應該知道 Rails 的架構和想法先進超出其他框架幾個世代之多。

Rails 的批評者最常對它的指責，總結起來大概就是這句：「市場上找不到開發者」且「只適合滿足技術狂人癮頭」的「效率糟糕」「不穩定」框架。

以前當我還是很菜的開發者時，聽到這句話會很生氣，但又不知道從何反駁起。但現在再聽到這種批評，我會心理暗笑對方是沒經營過商業網站的外行人。

事實上：世人的誤解，和真正現實的社會是這樣的：

PHP 的 Developer 好找，Rails 的 Developer 不好找

1. 挖來的「有經驗」的開發者，幾乎是不能對現有的團隊帶來戰力的。多數的情況，他只是用一門語言，埋頭重複寫了好幾年，從未自我進修與跟上現有開發技術潮流的開發者。他寫的 code 通常又會帶著自己的性格（無論是好的或壞的）。在一個團隊中，大家作事如果沒有建立起共同的 convention，越補人往往越只是災難。更或者，有些人寫 code 其實只是寫自己開心寫拿來炫耀的，從來不想考慮商業上的需求和穩定…

別懷疑，如果你希望有好的開發團隊，請自己養，別去挖別去找。要挖也要挖能幫你建立制度的人，自己也要努力幫忙貢與獻維持制度，也不需要害怕這個 Leader 跑掉，公司建立制度就是為了要保證沒有了誰還不會完蛋。（我出國深造，Team 也沒倒…）

而且，培養幾個 Rails Developer 的成本，真的比挖一大堆 PHP Developer 的成本便宜很多。

?

?

Rails 只是炫，對商業無貢獻價值

2. 現實的商業變動需求是很大的。Rails 並非只是五分鐘 CRUD 這種炫，沒辦法成事的東西。Rails 天生的良好的架構可以讓你可以不需要重造輪子，快速達成商業需求。剩下來的時間和力氣，可以用在把產品做的更好更棒。甚至把時間花在把原先的站修整成更好的架構。

當開發者不是處於事情多到做不完，每天寫的要死還是 deliver 出一個爛貨的狀態時。他將會有更多時間、精力甚至是心情，學習把事情做得更好更對。

（事實上，最近公司正在開發的產品，進度遠超過預期，提早三週寫完，RD 剩下來的時間都用在 refactor code，SEO，performance tuning，開心的 tune UI 等等…）??

?

Rails 效能糟糕透頂，所以使用它會陷入麻煩

3. Rails 效能是很不錯的，不要被那些謠言騙了。早在 Rails 2.x 時代，效能評測遠遠就幹掉了類似性質（full stack 型）的 framework。而且在公司裡，如果你想跟老闆說你想花時間 tune 效能，它只會回你一句，為什麼不買機器解決就好？Code 乾淨度和效能永遠不是商業運營需要考量的第一重點，除非它嚴重影響了你的商業營運與拓展需求（技術部主管要自己懂得拿捏這一點分寸）。

而且現實的狀況是，通常買機器的成本會遠比雇用 RD tunning 的成本低。如果還在草創階段，當然還可以咬點牙自己擠一點效能來調度。但別忘了，做生意就是要搞大，搞大了還要賺錢，如果你搞很大還不賺錢，沒有錢買機器，那是你這門生意有問題。不是 Framework 的問題。

永遠都不會是，別本末倒置了。??

?

Rails 變動過大，跟著升級網站會爛光，成本過高

4. 「變動太快導致不穩定，維護成本代價太大，所以不想用。」就更暴露了講這句話的人，原本寫的 code 可能本來就很髒、沒有寫 test、沒有用版本控制。更可能的是，根本不知道世界有這些東西的存在 XD

回頭想想，如果「一個框架」都「不變動」而且「更新不大」，那才令人害怕。那表示這個專案一點價值都沒有，沒人想貢獻。follow 一個沒有價值的專案，那才可怕…

另外，框架本身變動就需要更新嗎？那也未必，一門生意可以穩穩的跑還可以賺錢，為何要活生生搞爛它？沒事找事做，搞爛它把生意砸掉是你自己個人的愚蠢，從來就不是框架的錯。

?

?

採用 Rails 從來不是什麼辦家家酒的決定。如果想讓自己的公司業務快速拓展、自己團隊的開發者能夠迅速的跟上世界領先開發者的腳步、讓自己的開發團隊在寫程式之外，還有餘裕把產品做得更好更棒，你才更該採用 Rails。

Rails 在坊間的新手教學，基本就可以讓一個初上手的開發者達到一般人眼中的 Rapid Development 了。如果是這種快速 CRUD，很多人當然會說 XXX 也可以，為何一定要選 Rails？

但這種初階特性，及其開發速度。從來不是 Rails 開發者眼中真正 Rails 的價值，也不是所謂真正的 Rapid Development。今天這個 Talk 的主體，就是深入介紹一些只有進階開發者才知道的 Rails 之美、配合實務務經驗以及商業經驗，來達到真正恐怖的 Rapid Development。

Rapid Development，其實與 Rails 沒有絕對的正相關。只是 Rails 本身及其生態圈的發展與風氣，對於幫助發展 Rapid Development 有相當強大的正向力量。

一個專案的成敗，當然不只有開發工具暴力就行，還需要搭配其他的因素，如：團隊管理技巧、專案管理技巧、風險控制、商業運營 …etc.

不過，如果好的開發工具可以大量節省在開發產品本身時消耗的時間，那麼整個團隊將會有更多精力去專注在其他方向上，整體來說會提昇不小的專案成功機率。

?

查看更多 下一篇