[閒聊] 為什麼不用 Drupal ？

[olctw (olc.tw)]

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

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

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

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

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

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

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

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

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

# 效能

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

---

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

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

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

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

這篇可以搭配服用：
http://twpug.net/modules/newbb/viewtopic.php?topic_id=4020

--
kiang

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 42.71.71.205
推 cjoe:好像把Drupal換成Joomla，在這邊也說的通
Joomla 沒有 Drupal 那樣的堆疊架構，個別元件製作沒有 Drupal 模組那麼簡單，所以相
對不會那樣複雜些 ;)
※ 編輯: olctw           來自: 42.71.71.205         (03/17 14:27)
推 LaPass:兩個都是要花一段時間去學的東西..... orz
推 j87b0003:drupal其實要打包起來…真的是肥的要命…
→ j87b0003:不過他的設計概念還蠻有趣的
→ superpai:設計版型，依設計師出PSD交給themer製作的流程就好了
可惜國內一般專案的規模都太小，沒有足夠的預算去請 themer (frontend engineer)做這
件事情。在兼顧預算的前提下，要把這件事情做到完美，全部重寫可能簡單些，因為不會
有太多的干擾，而大部分的客戶也其實用不到 Drupal 這類型程式提供的彈性。
※ 編輯: olctw           來自: 116.59.242.15        (03/17 17:43)
→ hSATAC:就，不熟。大陸那邊比較多專業 Drupal 團隊把 drupal 用的
→ hSATAC:很精
推 LaPass:我覺得不熟的問題比較大.....
→ LaPass:要不然，其實寫個只有自己公司會的架構，讓別的公司一用就
→ LaPass:沒辦法把自己公司換掉，最好還用java或是asp編譯過不給code
→ LaPass:。這樣的效益還蠻不錯的..... 這種案子搞下去，價格都破50
→ LaPass:甚至破百的呢
→ Bambe:http://tinyurl.com/bfonkoz php cms的市佔比率
→ Bambe:只能說青菜魚肉各有所好囉
→ Bambe:w3tech 所統計的市佔：http://tinyurl.com/3438rb6
推 LaPass:PHP CMS我記得我去年還是前年看時是WORDPRESS最高的樣子
→ LaPass:怎麼沒xoop? = =|||
wordpress 最高已經好長一段時間了， xoops 經歷了一些分裂、鬥爭問題後已經元氣大傷
，台灣應該是少數 xoops 佔有率有感的地方，需要感謝台南那群老師們 ;)
※ 編輯: olctw           來自: 116.59.242.15        (03/17 21:32)
推 Leet:超同意 高度的彈性，也是高度的混亂
推 dspswen:推一下 感謝分享
→ superpai:我是覺得drupal的彈性就是高預算的案子才會用到..
推 silveriii:push
→ dlikeayu:http://www.kaixingocard.com.cn/ 我一年前寫的
→ dlikeayu:大至版面沒什麼變動，js有被換過 不知後來怎麼了
→ dlikeayu:裏面的module功能八成都自己寫的(主管要求)
→ dlikeayu:只用一些cleanUrl 跟內建安裝好的基本模組
→ dlikeayu:心得是，drupal基本架構比較沒有oo概念，寫起來很無聊
→ dlikeayu:這樣前後台(frontend全部，後台就上述八成裏的六成)
→ dlikeayu:花了三個月左右
→ dlikeayu:包裝好的東西的缺點就是你要去讀它一陣子來"使用"
→ dlikeayu:個人還是偏好framework的工具開發就是...
→ ilay:xoops已經是過去式了..
→ ilay:個人也是認同原po 但是真的要砍掉重練PHP的生產力又有限
→ ilay:個人是選擇跳到 py/ruby 陣營..