本文拖太久了，斷斷續續寫，寫到後來都忘記本來想寫什麼了。不過我發現，好像 thegiive 自己分多次，把很多我要寫的都寫完了。:-p

剛剛看到這篇《Twitter , Rails , Scalibility...More》，我哈哈大笑三聲。所謂的 scalability，就是「有沒有能力在短時間內應付突然爆增的流量成長」嘛！結果 thegiive 最後的結論竟然是：

那麼一時之間無法解決也是非常正常的事情。所以，他們應該也不是太懶惰，只是成功的太突然，沒辦法吃下來。…至於 Ruby 是不是真的太慢，Rails 是不是真的不夠 Scalibilty 呢？這個問題我也不知道…

既然這樣子，那我也沒辦法了，寫再多，又有何用，情人眼中出西施咩。所以剩下的我也就懶得寫了，各位看官自行斟酌吧。

這篇是為了回應 thegiive 的這篇《簡單的回應 JeffHung 的文章》，thegiive 對於我在《COSCUP2006》裡對 RoR 的一些意見，不表認同。不過在談技術之前，我想先澄清一點的是，這種很明顯地就是會沒有結論，甚至容易陷入 flame war 的問題，其實並不適合在那種場合提出 challenge，因為不會解決任何事情。用 challenge 這個字眼，其實也不太對，COSCUP 是個可以讓大家 up up 的場合，真的沒有必要白刀子進紅刀子出。事後的交流，也是可以產生火花，而且更為持久，一切由心，端看我們怎麼想，個人覺得實在是沒有必要那麼亢奮。

再好的 template engine，也解決不了套版的問題

我們先來看看套版的問題好了。也許是雙方對「套版」兩字的定義不同吧？我的意思是，在一般網站的開發過程中，程式設計師將動態網頁的功能寫好時，通常網頁的畫面是「素」的，非常陽春不經任何裝飾。接下來要做的就是，將轉交給版面設計師，也就是俗稱的美工，所設計好的華麗版面，套在這個「素」的版面上。對於程式設計師來說，這個「套版」的過程，通常是非常痛苦無聊的，但又不可能交給版面設計師處理，因為通常版面設計師，並無法處理到「碼」的層級。面對美麗的美工姊姊，小小工程師只好乖乖地與複雜的 HTML 混碼奮鬥。

更恐怖的是，通常來說，這個過程不會只做一遍，通常會形成一個循環，程式改好後套版，版面或程式稍微改寫之後，又要重新套版，循環不休。這當然是因為，在專案進行的過程當中，通常不可能很幸運地可以一條鞭式地順著瀑布溜下來。

對於套版問題，目前已經成熟的技術，是各式各樣的 template engine，如 PHP 的 Smarty。除了解決了 security-concern、separate-from-login 與 caching 等需求之外，簡單的語法，也讓套版的困難度，降低了少許。但無論如何，template 仍然是以「碼」的形式存在，要處理套版，仍然是只能讓程式設計師會版面設計，或者是讓版面設計師會寫點程式。

幸好，這個世界有在慢慢地改善，隨著 CSS/W3CStd. 的普及，以及 Ajax 的流行，套版的問題，將可以得到相當大的改進。如果網頁是功能性的，像 Gmail 那樣，比較好的解法會是使用如 ZK、GWT 這類的 Ajax framework，讓擅長處理複雜度的程式設計師處理套版；而若網頁是視覺性的，注重美觀與閱讀性，使用 CSS + semantic-rich XHTML，便可以讓擅長視覺設計的版面設計師處理套版。

但真正要解決套版問題，還是需要依靠「拉一拉」以及「WYSIWYG editor」，並且必須要做到，「版面設計師看到的是華麗的頁面，程式設計師看到的是素的頁面」以便應付隨著專案進行而來的修改循環。

那 RoR 有解決了套版的問題嗎？目前看來似乎是還沒有。雖然透過 Ruby 的語法，讓 RoR 的 template 十分地好用，但仍然是以「碼」的方式呈現，故仍然還是處於目前網頁技術的等級，並沒有什麼突破性的進展。更由於其「年輕」的特質，對應於 RoR 的「拉一拉」以及「WYSIWYG editor」的開發環境，相對於其他已經佔有市場極大份額的開發語言來說，能夠出線的機率就少了很多[1][2]。

Scale/performance 不僅僅是系統架構的問題，程式架構也影響很大

如果要單純比較 RoR 與 PHP 的 scaling 能力，搬出系統架構，實在是很沒有意義。不管前端是用 RoR 還是 PHP，server 都要 tune，系統架構都是要特別規劃的。並不是說 RoR 有 MemCache，PHP 就沒有，RoR 有 ViewCache，PHP 就沒有，或是 RoR 可以搭配 reverse proxy、multi-db，PHP 就不行。

使用 framework 最大的問題，就是程式架構的彈性。就如同 thegiive 所說的，「如果你希望一個框架就可以解決 Scaling 問題，不如先去問小叮噹比較快。」使用 RoR 增加了很多程式架構的彈性嗎？我反倒覺得陷在 convention 裡，是限制了程式架構的彈性。正如 thegiive 在 COSCUP2006 裡說的，如果是要開發一套全新的系統，那 RoR 非常適合；但如果是要與既有的系統介接整合，那 RoR 還力有未逮[3]。這是什麼意思呢？用白話講，就是：如果不照 RoR 的玩法走，那就幾乎是玩不下去了。Framework 的存在，通常是為了好讀好懂，好擴充功能而存在的。但實際的情形是，MVC 模型其實是個與 web/http 不太合的模型，硬要包裝成 MVC，代價就是程式的效能[4]。而更糟糕的是，透過 MVC 所減少的開發時間，與因套版問題而必須花費的時間比起來，常是九牛一毛。

因此，在使用 framework 反而會限制了程式架構的彈性時，「framework 能夠促進 scaling 的彈性」這樣子的陳述，就顯得有些弔詭。舉例來說，首頁的被存取量，相對內頁來說，通常大了很多。為了 scale/performance 的考量，在「程式架構」上，我們會把首頁裡靜態的內容部分，甚至只是較少更動的部分，使用 static-html-generation 的方式處理，事先或每個小時，重先產生。若是要按照 RoR 的「玩法」的話，這樣的機制，也不是辦不到，改寫一個 model 即可。但這就像為賦新詞強說愁一樣，脫褲子放屁。

ADO/O-R-mapping 與 SQL optimization

(...未完不續...)

參考資料

  1. 早在五年前，DreamWeaver 就已經提供了 ASP/JSP/PHP 的「拉一拉」以及「WYSIWYG editor」的開發環境。 ↩
  2. 另一個影響這類工具的現世的重大因素，便是該語言是否容易被程式處理。舉例來說，Java 的 refactoring tools 已經一大堆，但能夠給 C++ 用的，則是少的可憐。 ↩
  3. 大意如此，這裡無法字字精確地復述原話。 ↩
  4. 有同時在玩 lifetype 與 wordpress 的人，大概約略可以感覺得到，使用標準 MVC 寫法的 lifetype，執行的效能，還是比直腸子式的 wordpress 差了一些。 ↩