※ 引述《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)