: 其实不尽然 , 如果 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)