Re: [請益] Design Pattern在業界的使用

[cgfan (carryme)]

※ 引述《prag222 (prag)》之銘言：
DP 沒有這麼重要


能運作、好維護、好擴充、好調整 就是好設計
不應該"過度"把精力放在DP



有時只是"規模很小"的東西  某些組件用的次數也不多
你卻用了很精良的設計

- 浪費實作工時
- 降低修改與調整性 (受限於設計)
- 降低維護性 (不是每人都"精通"你的模式，維護後模式總是會分裂、突變)


結果，也許最"陽春"、最像新人寫的那種，說不定才是最好的。



寫code技術的演進流程:
1. Script code
2. 物件化
3. 模式化
4. 反樸歸真化 (有"需要"物件化才抽、有"需要"到模式化的規模才設計)






不過，在台灣

你還是全部都模式化保護自己吧，這是鬥code 時常用的工具阿。
很多專案就在這種鬥CODE風氣之下，逐漸突變


- 惡鬥造成團隊"過度"追求物件化、模式化、命名，這些無實際價值的東西
  而非把精力放在使用者，或著實際問題的解決與優化上


突變到無法收拾後，專案肥大到無法即刻隨使用者需要調整，
連調整簡單的"UI"，都有極高的維護閥值。




苦的是大部分人，笑的，是製造鬥爭，以假象哄抬自己身價的人。





說到底，還是終歸一句，這些都不重要。

工程師是做事的、還是生事的比較重要


: ※ 引述《Wolfken ()》之銘言：
: : Design Pattern不一定要用,但一定要會
: : 那本書裡面的pattern是一回事,裡面另一個重點是設計的概念
: : 它書主要是這樣,說明什麼設計會產生什麼問題,然後可以用什麼pattern解
: : 前面那個跟後面那個一樣重要呀,沒看過書你遇到爛架構還不會知道這是爛架構
: : 像是favor object composition over class inheritance
: : 信不信一大票號稱十年以上經驗的資深工程師
: : 寫出來的code還是一堆繼承然後很少interface跟composition
: : 然後跟你說我覺得很好呀,哪邊有問題?
: : 首先你得要有看出現在架構有沒有問題的能力,再來談要用什麼解決方案
: : 要不要用pattern,還是自己想的解法,甚至基於YAGNI原則暫時先擺著
: : 那是找出問題之後的事了
: : 簡單的架構問題,不用看書,大部份有幾年經驗的工程師都看得出來
: : 書中會寫的大部份都是就算十年以上經驗
: : 沒認真想過架構或是實際體驗過爛架構帶來的痛苦
: : 一輩子也不會找得出來的問題
: : 作者累積多年功力跟許多專案中爛架構的經驗,才能寫出這本書
: : 所以重點就是吸收他的經驗,讓自己找出爛架構的功力提升
: 首先感謝大大的回覆!
: 其實小弟是寫網頁出身的
: 工作經驗是從ASP網頁(維護)開始兼後端開發
: 小弟看一看Design Pattern也覺得是必學的
: 第一次看到用compoistion來解決設計上的問題,才發現進到了新天地
: 因為以往過去工作都找網頁程式設計
: 直到最近工作才覺得好像有點不太會寫程式
: 看了DP才覺得 程序程式導向跟物件導向程式設計的不同
: 坦白說這也是工作經驗跟學習領域不同的關係
: 看一看DP才覺得DP是學習OO Design重要的墊腳石
: 從另一個學習面來看DP怎麼用物件導向技巧實作解決問題
: 小小心得.....尚在學習,感恩....XD

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.105.178
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1479976581.A.49C.html
※ 編輯: cgfan (111.240.105.178), 11/24/2016 16:36:49
※ 編輯: cgfan (111.240.105.178), 11/24/2016 16:41:05
※ 編輯: cgfan (111.240.105.178), 11/24/2016 16:47:17
推 csfgsj: 設計程式的Pattern使用有時候會變成路線之爭，政治問題
→ dreamnook: 台灣是把嘴砲點高
※ 編輯: cgfan (111.240.105.178), 11/24/2016 17:03:21
→ pttworld: 工程師不太能決定是否使用framework，一開始做就有了。
推 youkoka: 說的好
→ viper9709: 推這篇
推 laject: 推返璞歸真