※ 引述《mc18 (无道德事业集团)》之铭言： : 外行人乱入回个文:p : 我觉得是该用什麽pattern, 或是该用什麽样的方法去实作一个需求时, : 这些东西决定的时机应该是在analytics - design阶段就该做的事情, : 但我相信有不在少数的人还是走所谓的"psuedo-agile-method", : 就是需求一来通常马上就eclipse打开开始写东西 : (谜: 为什麽是psuedo? 因为大多人写完了注解也很少, 事後reverse出来的文件也没有XD) : 在一个requirement出来时, 应该是要先将最基本的需求分析出来, 将它图形化後, : 这时候才开始进入所谓的design, 也就是开始做一些基本的static structure diagram. : 这些diagram并不是在design阶段就一次到位, 他是渐进式的, 有点类似画图, : 开始先构图, 然後修修构图, 最後上色 : (抱歉, 我的美术只有国小美劳课等级 ,至少我是这样画图的= =") : 在desgin也是一样, 一开始可能在classification後只是先将class的gen-spec关系定义好, : 慢慢地,才开始定义object之间的association relationshipe, 然而这是最重要但却最 : 容易被忽略的部分. : 所以这些东西, 我想不论是用什麽样的pattern, 应该是可以练习着不要让他只在脑中想, : 可以试着将它图形化, 这或许对整个static structure的design会有很大的帮助... : ------------ : ptt有OOAD板 XD 其实不尽然 , 如果 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 -- 虽然有预感这串的讨论串可能会离题的越来越远 , 不过我想表达的应该没有很难懂才对 , pattern 不是设计的终点 , 而只是一个开始 . --- 相关推荐参考书目资讯 写给SA的UML/MDA实务手册 http://www.books.com.tw/exep/prod/booksfile.php?item=0010386000 重构：改善既有程式的设计 (二版) http://www.books.com.tw/exep/prod/booksfile.php?item=0010411649 并特别推荐重构一书 , 可供已具有大量 coding 经验者比对设计/修改技巧. -- What do you want to have ? / What do you have? 从书本中，你可以发现我的各种兴趣。 从ＣＤ中，你可以了解我所喜欢的偶像明星。 或许从文字你很难以了解一个人，但从物品可以。 My PPolis , My past. http://ppolis.tw/user/Tony --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 221.169.78.140 ※ 编辑: TonyQ 来自: 221.169.78.140 (03/11 04:00)