您在這裡

首頁 » Forums » 綜合討論 » 閒話家常討論

Drupal 在客製化的哀愁

kiang's 的頭像
由 kiang 在 2009-03-28 (週六) 08:13 發表

Drupal 在客製化的哀愁

前一陣子接了一個以 Drupal 為基礎的震撼彈，說它是震撼彈的原因是，我花了比預期要長的時間去看懂程式運作；倒不是說 Drupal 難懂，而是這個網站前後有多位先聖先賢經手，其中還有比較陌生的、來自歐洲的朋友，最後到我手上時，沒有文件、沒有人說明、程式碼沒有備註、一堆變數、函式甚至用我看不懂的英文(也許是歐洲那位仁兄)拼出來，我在還沒看到這個榮景的時候就答應要承接專案，所以就硬著頭皮...

我所遇到的第一個問題，是要找出指定位置的內容是從哪個程式吐出來的，經過一陣廝殺後，大致有下面三個大方向：
1. 模組
2. 佈景
3. CCK + Views

好像很單純？精采的是，預設目錄已經有數十個模組，許多的程式邏輯被放在佈景當中，有些功能是在佈景覆蓋模組，有些模組被賦予多樣化的任務，CCK + Views 的組合除了資料庫外，在模組與佈景中被大量濫用與交叉覆蓋，於是，同樣一個觀察點，我可以找到許多重複的資料，但是只有一個是真的，而 CCK + Views 將程式碼藏在資料庫的特性讓我無法透過工具直接找到，還得登入管理介面才知道有它的存在。

這儼然就是一個需要整頓的環境，但是我被賦予的任務是為它加上更多新功能，而且時間並不充裕。

在幾經掙扎後，我放棄走正規路線，開始使用一些外部資源來設計我需要的功能，藉此繞過一堆凌亂的程式碼，不過這條路並不是那麼順遂，到後面發現部分功能有需要跟原本程式結合的地方，還是逃不開翻閱程式碼的命運。

在稍微進入狀況後，合約的時間也在不遠前了，我被迫用直覺進行程式設計，跳脫那種充分思考的理想畫面，先求將功能生出來；除了程式的修改外，還需要協助美工將畫面套用到程式中，這一段也出現了一些驚喜，因為部分畫面出現了一些合約以外的功能，或是原始設計並未思考文字過載造成的問題。

這個專案考驗的不是腦力，而是耐性，因為合約所載明的功能並不難，只是環境缺乏整頓對於時程的影響遠超過想像，最後產出的程式品質自己都不滿意，但是礙於時間壓力，只能將這諸多遺憾留給下一個看到驚喜的朋友(也許還會是我吧)。

心聲講完了，換些實際的東西。

CCK + Views 在 Drupal 客製化專案中是一大隱憂，因為程式設計師無法以熟悉的方式掌握處理流程，而重建這兩個組合延伸的功能卻要花上不少時間；再來，高彈性的背後就是高度的無效率，這兩個組合所產生的功能預期在使用人數增加時會成為效能瓶頸，特別是被放在經常需要存取的功能上。

因為 Drupal 的特性，其實一個模組就可以做到跟數十個模組一樣的事情，但是試著要打造一個萬能模組的同時，也讓後續的維護變的困難許多，而且一樣造成效能的問題。舉例來說，在 node_api 中對多個其他模組產生的 node_type 進行操作，未來在維護單一 node_type 時需要看多個地方，而且也增加了原本模組的負擔(像是在 load operaction 中加入特定資料)。

Drupal 有些方便的地方，像是透過 node_load() 或 user_load() 之類的函式可以取得許多需要的資料，但是這類型的函式並沒有太多控制選項，有時只是要一兩個欄位的資料，透過這種函式取得資料的背後是大量的查詢與效能負擔(因為它會觸發所有模組中包含特定函式的操作)，大部分情況下自行設計 SQL 查詢會比較有效率，當然，這需要多些程式設計的時間。

在佈景能夠做到比模組更多、更全面的事情，但也同時讓效能與架構變的更糟，如果時間允許，盡量把程式邏輯搬離開佈景會是比較明智的作法(至少如果下個看到的是我，我會有萬分的感激)。

畫面的套用可以很快，但也同時會影響到原本的程式，特別是 Drupal 許多效果是以 CSS 呈現，那些效果拿掉之後，就是會有些說不上來的遺憾。

如果希望長期發展，還是試著讓自己養成些好習慣吧，那種亂無章法的程式會讓下一個接手的人...總之，那也算是種業障吧 ;)

原始內容發表於下面網址：
http://twpug.net/modules/newbb/viewtopic.php?topic_id=4020

難怪前一陣子你說要到4月底才有空...
我現在接案子都比較保守，我會先對案子作完全面評估後才會跟客戶簽約，絕對不會在訪談時就做出任何承諾。

我不知道你的先輩們搞了什麼東西，不過我對你的態度很是讚賞，我個人是不太會對這種雜亂無章的東西妥協～
其實不只是 Drupal 的 CCK + View 會對你以前的流程處理產生衝擊，其他的框架也一樣。
CakePHP、ZF 你也玩的不少，應該理解我在講什麼。

至於你說程式放在資料庫裡，我記得這也不是啥稀奇的事，畢竟程式無法分割到合適大小成為模組時，作成小片段注入這也是沒辦法的事情。

我必須說，起碼 Drupal 還有這種方式不用讓你去動到模組的原始碼，這對後續維護系統跟模組作升級是一大助力。
你可以獲得後續的新功能，而不需要再打開原始碼找看看之前你改過的地方式不是需要再次 Patch，至少載管理介面的地方去修正你的程式碼是比較快速的地方。
缺點就是沒有專屬的 Code Editor 模組可以用～

這不算是 Drupal 的錯吧！我覺得網頁程式的「特色」。
今天你會 PHP, ASP，會發覺得許多網頁特效作不出來...
今天你會 JavaScript, CSS ，會發覺和 Server 控制不夠好, 被 瀏灠器的差異弄到頭痛。
今天你會 Flash ，會發現還是得向 PHP 或是 ASP 之類的程式要資料，而且互動其實並不即時。
今天你會.... 就會發現許多功能得靠其它語言才能達到。
今天你全會了... 就會發覺每樣東西都會得不夠，不足以作一個"漂亮的網站"。

把焦點拉近，Drupal是由許多工程師合力的成果。
原文書是到出版許久後才發行，而且還沒辦法帶到很深入的細節。
主要的目的是希望工程師「會用」，而不是全都能深入了解。
一部分的效能，是不得不作捨棄的。能有「高度彈性」又有「高度效率」的程式碼，我至今還沒遇到。
遇到不照規格的程式，會讓人有無從下手的無力感。(偏偏不懂程式的人常說「加個"小"功能不是很簡單嗎？」)

全部自己寫，自認為沒有這種功力。
發展那麼久的程式，早就處理了許多自己想像不到的問題。並不想全都經歷過一次。
自己也寫程式，也寫模組。會照著規則寫，也常在破壞規則，不論是有心還是無意的。
現實是殘酷的，沒有那麼多時間去學會「正統」的寫法，或是時間的壓力讓你不得不用硬寫的方式。
當然... 也有寫好的程式禁不起「改變」的因素而崩壞。

只能說，現今的網頁程式，已經不是一個人可以處理的了的。
只能在許可的時候儘量去照規格、以最好的閱讀的方式實作。
大家都有一樣的哀愁.....

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

那是我誤會了... XD
其實我沒有在批評啦~~ 就這篇文章讓人很有感觸就是了...
天天和程式為伍，天天需要在理想(寫出好程式)和現實(快速完成工作)中掙扎....

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

drupal模組的多樣性、擴充性、容易上手(以利用既有的模組而言)。會運用的話，要架站應該很快。

不過自從看過 Rasmus Lerdorf 的 Simple is Hard的簡報資料後，我感覺是 -- drupal架構很彈性，但也include太多沒必要的function.
看看 http://talks.php.net/show/froscon08/32，簡單的echo "hello world", 把db、mail...很多沒關聯的function都include進去。

另外就是hook、theme，都需要時間了解，所以要自己寫模組的話，門檻就比較高了。

坦白講，大部分All-in-one CMS / Framework 都在這樣在幹的 :P
在大系統下，scalibility和資金，eaccelerator 比起include效能來的重要多了 :)

--
from open mind to open source~

--
from open mind to open source~

CCK + Views 在 Drupal 客製化專案中是一大隱憂，因為程式設計師無法以熟悉的方式掌握處理流程，而重建這兩個組合延伸的功能卻要花上不少時間

好文，剛剛才看到這篇，老實說覺得寫的蠻有的同感的耶~

Drupal專案的開發方式，跟很多程式設計師平常受到的訓練和開發習慣有所不同 (不同，並不代表不好喔)
很多設計師，包含我，不管程度如何，多少都直接、間接的受到OO and Design Patten的影響
遇到問題，也使用這些Patten去理解、處理問題。
而Patten就像是程式設計師的【九陽神功】、【九陰白骨爪】等祕笈一樣，是前人遇到問題的處理經驗精華。

而Drupal架構自成一格，所以開發Drupal專案需要有開發Drupal的招式，有時就不能套用Design Patten
在看Drupal專案的Code也會跟一般的看Code方式不同 (因為邏輯不同)
例如Drupal的Module介面，一般傳統上可能會用abstract的Interface來定義，不過Drupal是採用naming rule方式處理
所以後續需要多型(Polymorphism)的場合就比較不易操作...

另外就是，用Drupal開發比較容易讓人會用View開始下去想、認識寫Code，比較不會用model開始下去想；
邏輯較不複雜的案子，這樣開發很直覺，也很快；
邏輯較複雜的案子，要在心裡默念三次，先把model想清楚，在去做View其他的。

這些很多可以用習慣去克服，或是只採用Drupal部分功能，像是為了維護一致性，不使用CCK等模組，只使用Drupal的框架和操作良好的被端。

至於效能與快速開發間的問題我覺得是trade off，大部分強調快速開發的平台都一樣，需要強調效能的部分就用傳統的方式處理 :-)

心得，Drupal是個好物，不過使用的人要找到適合自己使用的方法!!!
-------------------------
我在2008/12/12認識了Drupal

-------------------------
我在2008/12/12認識了Drupal

已經很久沒有接觸 Drupal 了，所以無法那麼「感同身受」，不過居然還是被感動了一下，這是字裏行間的魅力嗎? :D

非常認同 BB 的說法：

另外就是，用Drupal開發比較容易讓人會用View開始下去想、認識寫Code，比較不會用model開始下去想；
邏輯較不複雜的案子，這樣開發很直覺，也很快；
邏輯較複雜的案子，要在心裡默念三次，先把model想清楚，在去做View其他的。