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