> ==>发信人: [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