看完大家的心得 . 其實小弟蠻推崇 hoyo 大哥的說法的 .
而且小弟也不覺得跟語言有關係而是跟人有關係 .
小弟也報告一下個人一點點小小的心得 :
小弟覺得 mvc 其實只是個名詞 會因為 工程師的經驗産生不同的想法 .
設計出來的模組 差異化也很大 . 或許 讓 資深點的 programer 去設計 整個架構 .
會比較容易發揮 mvc 的精神 .
而且經驗這種東西也不是三言二語可以說明白的 .
有的工程師 寫個功能只要十分鐘 有的工程師寫個功能 要 一星期.
差別在 有的工程師 會花心思在 程式的 延展性和彈性上讓程式的重覆使用性及彈性發揮到最大.
有的工程師解個 bug 只要 花五分鐘 , 同樣的東西有的人確要解 上一整天 .
有的工程師則是看到什麼寫什麼 .
一樣都用 mvc 的楖念去寫可是差異就很大 .
例如
1. .net asp 小弟覺得 設計的很差 , 可是確很直覺拉一拉東西就出來了 但是 要速度快要好
維護 還不是挺好 它將 版型和 程式的邏輯偷偷做掉強迫 使用者會用它的模組就好 , 這
樣 對 程設師來說 細微的問題 真的蠻難掌 握的 不過如果覺得它的 模組夠用 那還ok 算
是蠻好的工具.
2. smarty 它可以分離 程式和版型 但是 實際上 對多層架構有常識的 工程師 會將
php 邏輯 與 smarty 版型遇輯要做的事分清礎 因為 smarty 可以下版型邏輯 .
版型上的事就交給 smarty 做 不要給 php 做 才可以讓程式富有延展性和一致性 開發的
速度才會又快又好維護
3. XML + XSL 它的功能同 smarty 不過它 的 版型邏輯 是標準化的 可以跨平台誇程式語言
也就是 只要吐出來的xml 一致 xsl 就會將 畫面給處理出來 .
結何上述的想法 , 後來 小弟 最近幾年 慢慢對自己開發的環境 設計出一些 適合自己用的開發元件 ,
初期 的想法 是
好煩 每次 新增都要 對 資料庫 所以我 寫了一個 function 只要 給參數就會 新增 且跳回指定的網頁 .
好煩 每次 刪除都要 對 資料庫 所以我 寫了一個 function 只要 給參數就會 新增 且跳回指定的網頁 .
好煩 每次 拉 換頁的 record 時都要 對 半 天 所以又寫了一支 專叫 record 的 function
每次處理換頁 都要重新拉一次 用 call function 吧 .
結果整理出 :
一個 完整的功能不外乎是
新增 修改 刪除 record search sort sitemap relation ..............
結果全都寫了一個 function , 這時 smarty 或 xml 就有用處了
因為它可以讓 php 邏輯 和 版型邏輯有一玫性和延展性 .
所以 新增 修改 刪除 record search sort sitemap relation .............. 吐 出來的資料 讓它的格式都一樣 .
ok 這樣一來 所有叫用 content layer 的程式我都不用寫了 只要 給參數它就會 幫我 叫出來
我也不用考慮 bug 或 測試的問題了 .. 節省 1/10 的時間了 .
所以我的程式是長這樣的 ^^!! 我徒弟 第一次看到時 坐在 電腦前發呆蠻久的 不過教一教 一下子就會用了
再來 這些東西我幾乎都不自己寫 而且這些東西也會強迫底下的人沒法子寫出一些恐龍程式出來 :
<?php
$max_page = 10 ;
$max_range = 10 ;
$table_name = "fun" ;
$default_sort = " order by seq asc" ;
$search_str = "
: and : pjid : = ,
: and : id : like :% :% ,
: and : name : like :% :% ,
: and : node : = ,
: and : layer : = ,
: and : link : = ,
: and : descript : like :% :% ,
: and : message : like :% :% ,
: and : open : =
" ;
$sort_str = "
: pjid ,
: id ,
: name ,
: node ,
: layer ,
: link ,
: seq ,
: descript ,
: message ,
: open ,
: idatetime ,
: sdatetime
";
$relation_str = "
project : id : name
";
$insert_str = "
pjid,
id,
name,
node,
layer,
link,
seq,
descript,
message,
open,
idatetime
";
$update_id = "
id
";
$update_str = "
pjid,
id,
name,
node,
layer,
link,
seq,
descript,
message,
open,
idatetime
";
?>
再來是版型 同理 , 我發現 page relation sort ........ 去吃資料的邏 輯也有一定的rule
好吧 那我 也設計出幾個 block 要用時 直接把 block 指向 吐出來的資料就好了 .
............. 結果 一個功 能 :
新增 , 修改 , 刪除 , 排序 , record list , 換頁 , sitemap . 老實說 不用十分鐘就可以寫好了 .
節省大量的開發時間再來花 個二十分 檢查一下 .
開發專案時 , 設計 一個 八十個 table 的 專案 大楖 設計花了 一二個星期 , 可是寫的話 只要 四五天左右 而且還不用很趕 一天寫十六個功能 也就是半小時 寫一個 可是其實參數填進去 版型參數填進去 只要花十分 鐘 還有二十分在 聊天打屁 .
這意味著 只要 sa 夠力 , 設計出來的東西一次 ok 底下多找幾個 coding 的人
用 設計好的模組狂抄 生產力 是很可怕的 , 也許一個月就是其它公司 一整年的產能以上 .
再來是測試除錯 大楖要花 一二個星期 ,.
小弟發現 也就是說在 這個軟體愈來愈進步的年代 , 以前的開發習慣 及語言的限制 .
就好像是 家庭手工或是手工藝品 一樣一件件 慢慢的做出來 .
而 目前的工具發達到 則是 像工業時代一樣 生產速度 是以往的幾十倍幾百偣 .
資深的工程師就像廠長一樣 接到訂單 塑模 開模 訂生產線 準備大量生產 .
資淺的工程師就像 工廠的作業員 .
而模組就是機器 不停的把材料打出來給 作業員去 包裝 .... 生態好像變成這樣了 ^^!!
一個 良好的架構讓 開發程式變的輕鬆好玩又快速又有效率 , 真的事在人為 .
也許大家不要再把心思放在 語法和流程 把時間放在 設計上 會覺得程式設計是一個蠻好玩東西 .