Drupal 在客製化的哀愁

edited 十月 2013 in 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/x/modules/newbb/viewtopic.php?topic_id=4020

評論

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

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

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

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



  • edited 三月 2009
    與其說是drupal的哀愁
    倒不如說是php在framework化之路上的矛盾
    基於開放原始碼的特性上
    導致你寫你的class我包我的class這種無法一統的亂像
    framework雖然在某種程度上縮短了開發的時間
    實踐了分工撰碼的真諦
    但對coder來說php的freamwork仍是兩面刃...
Sign In or Register to comment.