> ==>發信人: [email protected] (pig), 信區: programming > ※ 引述《StubbornLin (Victor)》之銘言： > : 而我現在寫程式如果想要能有很好的擴充性和重覆利用的能力 > : 就必須花很多時間去思考架構，我目前用的方式是慢慢增加功能 > : 慢慢調整各個組件，在整個過程中將架構做出來 > : 可是我發現這樣很沒效率，如果是按圖施工的話就不一樣 > : 速度非常快，但是一開始只想，然後再去做的話 > : 有時會在寫時才發現某些細節有問題... > : 所以我在這裡想問，程式的架構到底該如何去想比較好 > : 先用一般的方式寫一次再來拆? 還是.... > : 不然要顧慮的東西太多，變成沒辦法專心在解決一個問題上 > : 所以很難構想... > : 謝謝 > 我也在思考這個問題...我覺得如果能夠將抽象的軟體架構以圖形的方式來描述 > 將會使整個軟體系統運作的更好 做硬體電路的是先畫功能方塊圖, 再思考控制訊息與資料如何銜接. 就明顯有 data-flow , control-flow 兩種接線. 古早的程式是偏重如何處理資料(變數名稱)的處理次序流程圖, 因 圖解佔篇幅, 後來就是 pseudo-code 條列指令形式的 algorithm 表示法. Algorithm 只是小方塊的處理程序, 像零組件. 架構就涉 及大方塊間的流通與處理數量, 方塊間的前後上下關係. 軟體都被認為比硬體複雜, 就是因為一時理不出個清楚的功能模組 方塊, 有了方塊也不知如何實現(凝聚的功能需求不明, 算法也不 明), 通常是不知如何切割, 在何處切割. 切割出來的那一塊該如 何稱呼其功能, 以便能再利用. 如果弄清 藕斷絲連的藕合 (coupling) , 同體凝聚 (cohesion) 的意義特性就容易體會, 圖解表示的好處, 就是會很具體看得見. 如果很誠實的把關係畫出 來, 結果像是一團意大利大雜麵, 那就是切錯了. 在 UML 出來之前, 軟工做分析, 表達架構的方式都是畫 relation graph 的圈圈泡泡圖. ====================== 寫程式很像 "作文" , 先定段落會好寫得多, 如果是 "八股公文", 用 "格式填空" 就能自動產生. 印度的代工並非用一堆手工工匠來 做手工藝品, 而是用格式填表, 很像半定製型半自動化的生產線. 台灣的軟體工程失誤處是陷入 "企圖全自動化" , 硬體製造業的生 產線沒有被學術界重視, 所以一直是走半自動化的路線演變, 反而 VLSI 設計是講究自動化的. 軟體沒有切隔出重點, 未能區分出可為 與不可為的部份, 又被學術界論文發表所迷惑, 被拖往全面自動化 (不如此先進的掰, 如何是領先世界的論文 ?) 分析設計規劃的問題, 免不了策略性的選擇, 更免不了挑戰傳統的 突破 ! 凡事過猶不及, 恰到好處就是難 ! (不過, 事後諸葛容易, 但事後都仍弄不清楚為何敗陣就不好了) -- ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234