※ 引述《Reinhard (飛鳥盡 良弓藏)》之銘言： : 最近對於這個問題有點小疑惑。 : : 以前很執著於一定把架構先架起來， : 也就是先用 comment 寫寫 pseudo-code，function 的宣告，data 的傳遞 ====== 也就是說 有個構想(顯然會有個標的), 就做了架構的假設(通常是模仿 或選擇出來的), 然後做 Functional Decomposition , 開始功能方塊 與輸出入的設定, 所以開始有 function 宣告, 資料結構的設定與資料 項的傳遞. : 都先寫好，再從底層開始慢慢架起來。 : 心情好的話，甚至會對底層的一些小模組進行測試。 : : 不過這樣寫有幾個缺點： : 首先是前置作業太長，會覺得自己花了好多時間卻沒什麼進度，感覺不佳。 : : 第二個缺點其實跟前面有點關聯， : 就是在這種 bottom-up 的作法之下， : 直到兜起來的那一刻才能比較成品跟自己想法的差異。 : ======== 這是 Top Down Design 的思惟沒錯, 由大架構到小方塊. 實作當然是像蓋房子 由一塊磚一塊木一層層, 從最常共用的元件開始做上去, 實現免不了就是從平 台 buttom-up 疊上去. 如果是自己一個人做這件事, 怎麼會發生 "成品" 跟 "自己想法" 的差異 ? 尤其元件是 "全部" 自己做的, 怎麼會發生做的跟自己期望的有所不同 ? 如果 真是這樣, 那就是個人認知的程式處理與其結果跟電腦的處理有所不同, 這是 個人對程式碼執行後認知的差異, 也就是個人下給電腦的命令跟心中期望有差 距, 這個用甚麼方法無關啊 ! : 所以後來就比較傾向先作一個小小的、有點簡略的版本， : 想到什麼先做什麼，再慢慢 refine 的作法。 ====== Top Down Design 的構想是大的目標概念, 架構則是必要的組成, 可以先從簡 略的功能開始, 慢慢補全或增填增強提升方塊內的功能, 那是 refinement. : : 不過這也有缺點，整個架構不夠好的話， : 經常會有挖西牆補東牆的感覺。 : : 不知道大家都是怎麼做的呢？ : ====== 要發生挖東牆補西牆是實作的時候才會發現, 兩片牆很像, 只是某個位置 不太一致, 就拿那個很像的來改來 "共用" , 想 "整合濃縮成一種牆" , 結果卻是弄得兩片牆甚麼都不對勁, 這是凝聚與分割沒處理好, 也就是功 能分割出狀況. ======= 這是我的理解, 參考一下, 也請指正. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146 ※ 編輯: ggg12345 來自: 140.115.1.146 (11/27 07:17)