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