Re: [討論] Optional operation 的使用時機?
: 其實不盡然 , 如果 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
我無法同意你更多:p
不過話說回來, 其實圖跟code是一體的, general一點就是他們都是文件, 只是程式碼是
可執行的文件而已.
先有圖不一定是最好的做法, 現在有一群人開始提倡agile method, 就是提昌提升大家的
溝通能力, 讓文件就在程式碼中(註解), 事後再用reverse tool產生部分文件. 但傳統做
法中(在這不考慮EERD), 圖有的能力其實是很大的, 舉例來說, 當需求出現時, 就可以做
出相對應的use cases, 然後定義relation變成一個diagram, 然而這些use cases如果定
義得當的話, 就會是未來functional testing的依據, 可以做為單獨的test case範本.
我會提到有些東西要再design階段完成是因為某些pattern他能夠讓我們在定義某些
diagram後得到答案, 最簡單的例子莫過於singleton, 因為在決定association的階段,
我們就能夠"大略上"確定object跟object之間需不需要控制實體的個數.
UML tool我現在還在用很low的ArgoUML還有StarUML, 公司沒補助想用免費的可以考慮
看看:p, 不過跟VD以及Posseidon等比起來真的是LP比雞腿, 沒得比的...
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.251.172.154
※ 編輯: mc18 來自: 60.251.172.154 (03/12 14:07)
※ 編輯: mc18 來自: 60.251.172.154 (03/12 14:09)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 7 篇)：