為什麼不用 Drupal ?

edited 十一月 -1 in Drupal
Drupal 功能強大,而且世界知名,但是經手的許多專案中,都是將 Drupal 換掉,針對需求重新改寫,這裡聊聊一些我所看到的原因。

# 沒辦法直覺找到需要的功能

傳統的程式設計中,我們會針對前台看到的選單設計對應的管理功能,讓使用者可以輕易的找到希望調整的內容。但 Drupal 將內容抽象化後運用在大部分位置,因此不管產品、新聞還是工作團隊的介紹,都統一透過一個介面管理,再依據內容類型的不同產生表單,這是許多習慣舊有程式邏輯的朋友面臨的第一個挑戰。對於一個年輕人來說,這樣的改變很容易接受,但年紀稍長的朋友可能就不這麼想了,他們還是希望清楚的分門別類就好。

# 要讓畫面長得跟畫出來的一樣,好難

許多網頁設計人員還是習慣著先將所有的畫面透過繪圖軟體完成,接著切割後套用到程式中,但這在 Drupal 行不通,或者該說,要花非常多時間去完成這件事情,而且讓人沮喪的地方是,很多小細節是牽一髮而動全身,很多的時間花在這樣子來回的調整中。有經驗的朋友知道,應該要先了解 Drupal 的架構,然後依據架構去產生設計,這樣才可以避免衝突情況發生,但這件事情要說服傳統設計人員可不是那麼容易,特別是那些已經在設計界小有名氣的設計師,他們總能夠把 Drupal 批評的一文不值,即使他們也知道美國白宮就用這玩意兒。

# 現有的資源豐富,但並不是每個模組都有成熟的發展

專案開發的程式最常會發生,為了要達到合約書上的要求,儘管使用的模組並不是非常穩定,也會把它放入交出的成果中,想辦法等到驗收完成,然後就不再回頭去想這件事情。但並不是每個故事都有完美的結局,這些不定時炸彈還是有引爆的時候,這時候如果不是避不見面,大概就是得熬夜一陣子了。即使有這樣的問題,人們還是習慣走上捷徑,因此這樣子透過不穩定的模組產生的網站還是陸續誕生中。我們遇過幾次這樣的網站,也曾經試著將它的問題修正,但我們發現這樣子要比重新改寫還花時間,所以我們後來都選擇全部改寫。

# 高度的彈性,也是高度的混亂

Drupal 的彈性設計讓玩家們似乎找到了一個宣洩自己想法的管道,因為不需要熟悉程式設計,就能夠透過多種方式組合出自己想要的功能,很多時候這樣的組合過程複雜到他們可能自己再也想不起來,但他們還是樂此不疲。但也因為功能的組合過程複雜,許多的資訊分散於資料庫與檔案中,當這樣的功能需要修正或延伸時,往往會不得其門而入。但並不是每個人都會就這樣放棄的,我們因此看到了許多更精彩的 "暫時作法" ,其中不乏直接針對核心程式開刀的情況,即使知道這樣子未來更新會很多狀況,但專案時程就在眼前了,想辦法度過這一關再說...

# 效能

預設的 Drupal 其實效能不差,效能的瓶頸往往出現在組合了大量的功能之後,因為 Drupal 將內容抽象化重複運用,造成了大部分的延伸功能都直接往內容( node )架構進行堆疊。在傳統程式設計,因為內容是各自獨立的,所以只有邏輯複雜的內容處理起來會比較費時,但 Drupal 讓網站中只要有邏輯複雜的內容存在,就 "大家一樣慢" ,也因此消耗了大量不必要的資源。

---

其實上面的問題都可以獲得解決,只是人們往往不願意花太多時間、資源在遵守 Drupal 的準則,這時候 Drupal 提供的彈性就成了它的原罪,出現了許多誤解。我們只是一個小規模的專案開發者,不太能夠在每個混亂的局面中引導客戶走向正確的道路,所以大多選擇了最快的方式:既然這條路打結了,我們另外開一條給你走

Drupal 的功能強大還是值得玩味的,不過有意願持續陪你玩的客人不多,畢竟大家都想把錢花在刀口上,是吧?

有些問題不是 Drupal 專有的,但我們遇到比較多混亂的狀況是在 Drupal 建置的網站,因此感觸特別深吧 ;)

來源: http://blog.twpug.org/527

原始討論: http://twpug.net/x/modules/newbb/viewtopic.php?topic_id=7259

評論

Sign In or Register to comment.