您在這裡

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其他的。