Re: [討論] Optional operation 的使用時機?
※ 引述《mc18 (無道德事業集團)》之銘言：
: 外行人亂入回個文:p
: 我覺得是該用什麼pattern, 或是該用什麼樣的方法去實作一個需求時,
: 這些東西決定的時機應該是在analytics - design階段就該做的事情,
: 但我相信有不在少數的人還是走所謂的"psuedo-agile-method",
: 就是需求一來通常馬上就eclipse打開開始寫東西
: (謎: 為什麼是psuedo? 因為大多人寫完了註解也很少, 事後reverse出來的文件也沒有XD)
: 在一個requirement出來時, 應該是要先將最基本的需求分析出來, 將它圖形化後,
: 這時候才開始進入所謂的design, 也就是開始做一些基本的static structure diagram.
: 這些diagram並不是在design階段就一次到位, 他是漸進式的, 有點類似畫圖,
: 開始先構圖, 然後修修構圖, 最後上色
: (抱歉, 我的美術只有國小美勞課等級 ,至少我是這樣畫圖的= =")
: 在desgin也是一樣, 一開始可能在classification後只是先將class的gen-spec關係定義好,
: 慢慢地,才開始定義object之間的association relationshipe, 然而這是最重要但卻最
: 容易被忽略的部分.
: 所以這些東西, 我想不論是用什麼樣的pattern, 應該是可以練習著不要讓他只在腦中想,
: 可以試著將它圖形化, 這或許對整個static structure的design會有很大的幫助...
: ------------
: ptt有OOAD板 XD
其實不盡然 , 如果 analytics - design 時期就能決定所有的事情 ,
那也就不會需要 refactoring 這個強調「再一次機會」的觀念 ,
幾乎所有時候第一次分析之後 , 所得的結果都不是最終的正確解 .
（以上指的是在我的經驗之中 , 如果有人常常一次ko歡迎指正.XD）
事實上光是要需求明確這點 , 恐怕就現在的環境而言就很有困難 .
讓我想起之前再跟 qrtt1 前輩討教關於 test-driven 開發時 ,
光是第一個前提要有明確的測試條件(需求) 這點的確就夠讓人傷腦筋了. :p
要嚴謹的說 analytics - design 時期的話 ,
現在台灣 pg 有多少人能有幸進入都還可以打上個問號 .
想做而不能作跟能作而不能作是有出入的 , 這點你應該不會不知道才對 ,
不過這跟我原本想講的已經離題太遠了就是 , 拉回來 .
────────────────────────────────
當然規劃是仍然必須的 , 我想表達的是 pattern 不是一個選擇使用的工具 ,
而是一種融入在程式人心中的概念 ,
就比方說我們在算一週可以ko一個案子 , 所以三週可以 ko 三個案子 ,
我們不會特地強調這是用線性的方式推算出來（為什麼需要強調？） ,
而只是單純的用經驗或者直覺去類推出這樣的結果 .
pattern 也是一樣的 , 當強調是用 xx pattern 解決問題 ,
而不是問題被解決時 , 通常往往也同時是另一個問題的來源......
(當然 , pg 彼此溝通問題細節時不在此限.)
我覺得 coding 這件事情 , 常常人們會陷入「為作而作」的困境而不自知 ,
就像重構一書中序文中譯者所提到的 , 重構當瞭解後就有如空氣跟水一樣 ,
我是認為其他的設計技巧其實也是一樣 . (recurive, design pattern ,etc.)
────────────────────────────────
既然提到圖形 , uml 圖非常適合表達流程、資料 ,
現在比較常用的是類別圖、循序圖、活動圖及狀態圖 ,
基本上需要的表達圖形都有 , 圖形也不會偏離直覺太遠 .
（對非pg還是要逐一解說就是。）
(btw , judy 真是個超棒的 uml tool!)
另外分享一本書給各位版友 uml4sa （全名：寫給SA的UML/MDA實務手冊） ,
這本書是透過一個實際專案跟訪談過程來呈現 uml 圖的生成過程 ,
雖然有些項目略嫌繁瑣 , 不過對於不瞭解圖形意義的朋友們應該有所助益,
雖然在虛擬碼可以呈現的前提下 ,
我始終認為好（可遇不可求）的程式碼是最佳的註解 .
────────────────────────────────
OOAD 版也是個有趣的地方 , 之前也在上面討論過神之物件 ,
但這兩串一來是延伸之前的問題,
二來是設計跟實做之間的差距往往是最難上手的地方 ,
這兩串文章很顯然都不在討論設計方面的優劣 ,
而是實做上可能會採用的狀況跟為什麼會這樣做的理由.
"為什麼明明可能有更好的設計 , 但仍然有人可能會選擇這樣的設計 ."
1.更好的設計可能有其他環境上的問題
2.沒有想到這樣的設計（能力/認知不足）
3.其他可能的理由
我還是認為比起討論何種設計比較理想 , 這種實務上面的檢驗與回饋 ,
當然還是在原生環境上比較容易得到結果囉 ,
要把語言那一層也抽象走 , 對於實務往往就更難討論了 ... :p
當然哪些問題該歸類到 OOAD , 哪些問題該歸到語言本身 ,
這個問題本身應該就是值得討論的一個大問題了. :p
--
雖然有預感這串的討論串可能會離題的越來越遠 ,
不過我想表達的應該沒有很難懂才對 ,
pattern 不是設計的終點 , 而只是一個開始 .
---
相關推薦參考書目資訊
寫給SA的UML/MDA實務手冊
http://www.books.com.tw/exep/prod/booksfile.php?item=0010386000
重構：改善既有程式的設計 (二版)
http://www.books.com.tw/exep/prod/booksfile.php?item=0010411649
並特別推薦重構一書 , 可供已具有大量 coding 經驗者比對設計/修改技巧.
--
What do you want to have ? / What do you have?
從書本中，你可以發現我的各種興趣。
從ＣＤ中，你可以瞭解我所喜歡的偶像明星。
或許從文字你很難以瞭解一個人，但從物品可以。
My PPolis , My past. http://ppolis.tw/user/Tony
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 221.169.78.140
※ 編輯: TonyQ 來自: 221.169.78.140 (03/11 04:00)
推
03/11 23:20, , 1F
03/11 23:20, 1F
推
03/11 23:51, , 2F
03/11 23:51, 2F
討論串 (同標題文章)