Re: [徵文] 軟體工程師入門

看板Soft_Job (軟體人)作者 (寂靜的生存者)時間10年前 (2016/04/04 22:59), 10年前編輯推噓4(4013)
留言17則, 9人參與, 最新討論串5/6 (看更多)
※ 引述《csfgsj (真理不滅)》之銘言: : 前文已經拉太長不好閱讀,用回文的方式接續~~ : : → NodeWay: 知道一萬種DP果然是大師 在下才疏學淺只數得出二十來種 04/04 1 4: : : 推 RunRun5566: 我理解的Design Pattern大概只有十幾種 04/04 1 5: : : → Masakiad: DP並非用一種或數個架構要解決「所有」問題。DP是在特定 04/04 1 5: : : → Masakiad: context(姑且稱環境)下產生的force(姑且稱問題),可 04/04 1 5: : : → Masakiad: 以用同一種pattern去解決該force。但很多人忘記必須考慮 04/04 1 5: : : → Masakiad: 該pattern產生相對應的force可能影響整體架構。但其實DP 04/04 1 5: : : → Masakiad: 是有強調可能照成的相對force。另外pattern不指code或定 04/04 1 5: : : → Masakiad: 型的class diagram,因為他意義上是指解決該force的一 04/04 1 5: : : → Masakiad: 種固定手法,依我的能力這可能很難言語講明白。但patter 04/04 1 5: : : → Masakiad: n包含由原概念產生的變形也算。所以pattern一直很少。 04/04 1 5: : 從以上的敘述,我想我大概明白你的意思,也同意你的看法 : 因為你說出了一個重點: : 「pattern不指code或定型的class diagram」 : 這跟OOSA、OOSD的論點比起來,清爽多了 : (做蛋糕為何一定要用大便做原料) : 對你的看法,我的認知,其實可以用更傳統的詞彙來描述它 : Force =:特定環境下的特定作業(管理)需求。 : Ex:開一家餐廳,要如何營運 : Pattern =:為滿足這個需求,所採取的作業模式、系統模型等.. : Ex:餐廳的營運模式:客人進來,先看菜單、點餐、上菜、享用、結帳、離開 : 而同樣的作業模式,可能在若干其他不同的地方 : 雖然環境需求不見得完全相同,卻能似曾相似地被使用著 : Ex:K 房的營運模式:客人進來,大閱兵、點?、上?、享用、結帳、離開 : (跟餐廳的營運模式很像?) : 因此類似這種,被很多不同地方同時套用的作業模式 : 就成了作業設計規畫者的一個,經典的問題解決方案 : 一個參考範例,一個模式罐頭 : 範例收集的越多,則能解決問題的辦法就越多 : 如您所述,當你收集了20種以上不同的模式罐頭 : 也就差不多能應付所有的管理作業問題了(大架構) : 系統設計,也就只是在這些模式罐頭間,選擇合適的套用 : 大的系統,可能要同時套用許多不同的模式罐頭 : 之間的交錯又可能衍生出新的組合型模式罐頭來 : 反過來看,要分析一個現成的系統 (系統分析),也就是在觀察 : 該系統用了哪些模式罐頭參考例內的模式 : 當該系統所有模式都清點解析完了,還不用涉入code的實作細節 : 對該系統的了解,就已經差不多達到七八成了 : 以上就是該系統的領域知識,這些都與程序語言無關 : 對於腦袋裡沒有什麼模式罐頭觀念的人 : 去看一個大系統的Code,只能說「只在此山中,雲深不知處」 : 迷路了不說,還很容易被大量的code淹死 : 研究作業模式,了解模型的哲學,才能應付這種問題 我是一位初窺大道的工程師 對於一些想法想和同輩交流 我認爲Design Pattern 寫到後面都是在解耦 並抽換物件 這東西像太極拳,當你忘記那些框框架架 善用基礎物件導向特性,當遇到事情複雜度和過份耦合上升 才要考慮是否要重複利用再考慮採注入或者抽象複寫方法 並理解不該把過分變動放到父類別等一些簡單設計原則 噁...說真的除非你對於系統的domain充分了解, 才能設計彈性和可擴充功能SOLID 不然都是邊做邊修 我看過太多硬要用模式而產生失敗的例子 建議初學者應該要加強語言特性和工具掌握度,並有基本OO概念 掌握Trace Code技巧,大概就踏出第一步 最後更上層進步法 怎樣板美容方法等等,轉接頭鴨子等等一些生活例子 接下來則是學習掌握本質和讓程式說話的技巧 好的程式是不用太多註解就會自己表達 軟體這條路真不管真理 歪理 只要能解決業務端問題 不會有人管你怎麼寫 除了工程師維護時會罵髒話 End -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 39.13.10.94 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1459781988.A.5CB.html

04/04 23:05, , 1F
這只是對DP 不懂的人的說詞,君不見本版動不動就DP一下
04/04 23:05, 1F

04/04 23:05, , 2F
就知,只要有DP, 隨便都有好程式.
04/04 23:05, 2F
※ 編輯: gn01838335 (39.13.10.94), 04/04/2016 23:07:13 ※ 編輯: gn01838335 (39.13.10.94), 04/04/2016 23:10:32

04/04 23:26, , 3F
程式是用寫的 不是用講的 太多講的一嘴好程式的人了
04/04 23:26, 3F
認同 但是要當管理職要會嘴程式 XD 我也初窺大道,重構很多程式有感而發 ※ 編輯: gn01838335 (39.13.10.94), 04/04/2016 23:29:56

04/05 00:10, , 4F
"只要有DP,隨便都有好程式",1F確定?
04/05 00:10, 4F

04/05 01:02, , 5F
註解喔 我還是覺得一定要至少寫上大綱... 就算名字取得再好
04/05 01:02, 5F

04/05 01:03, , 6F
你永遠也無法保證下一個看你程式的工程師英文程度如何...XD
04/05 01:03, 6F

04/05 03:03, , 7F
樓上註解是用中文寫?
04/05 03:03, 7F

04/05 03:09, , 8F
我個人對DP的見解是,當你覺得遇見相同模式的問題能
04/05 03:09, 8F

04/05 03:09, , 9F
很快且自然的聯想到解決方法,而不用在那邊想半天該
04/05 03:09, 9F

04/05 03:09, , 10F
用什麼方式去處理,這就是學習DP優點。別走火入魔的
04/05 03:09, 10F

04/05 03:09, , 11F
話,多學習一定是有益無害的。
04/05 03:09, 11F

04/05 07:29, , 12F
不要忘了,OO的框架,可都是一種硬框架,用起來問題一堆
04/05 07:29, 12F

04/05 11:25, , 13F
/*唯一支持註註解*/ XD
04/05 11:25, 13F

04/05 19:56, , 15F
用中文寫有什麼奇怪的?公司裡沒有外國工程師阿
04/05 19:56, 15F

04/06 09:07, , 16F
我覺得物件導向是很美妙的設計
04/06 09:07, 16F

04/06 17:07, , 17F
美麗的東西總是充滿陷阱
04/06 17:07, 17F
文章代碼(AID): #1N0e5aNB (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1N0e5aNB (Soft_Job)