张云贵(477***9) 17:06:43
不知其他公司怎么样，我们公司多数开发人员都不熟悉UML建模，只画类图、简单流程图、很粗的架构框图。我对UP、全程建模很反对，觉得敏捷建模挺实用，你们是怎么做的？建模多吗？
毛辛荣(360440923) 17:07:48
难推 往往受工期影响
张云贵(477***9) 17:14:59
我想推的和同事想学的差得大，不好弄
潘加宇(3504847) 8:39:02
上课的最后都要说的：每次改进一点，先改短板。
改进指南，参见群共享umlchina9_tips.pdf
潘加宇(3504847) 8:41:24
建模是显示思考的技能，你不思考问题不会自己消失，逻辑也不会自己理清楚，无非是拍脑袋碰运气思考还是严肃地有套路的思考的问题，这是业余和职业的区别
佟太丰（安捷睿(318***73) 10:09:10
非常同意
张云贵(477***9) 16:36:35
《软件方法》里说开发人员更喜欢画"草图"，其原因是想通过形式的粗陋掩盖内容的粗陋。我有个疑问，对于国内中小型软件，没有足够时间去正规建模，使用简化的包图、类关系图、局部序列图、状态图也能把软件设计出来，即使多数是通过画草图形式进行思考设计也很管用。请问这里面是不是存在认识上的错误？谢谢
梨树下(629***8) 16:39:47
如果"草图" 不是一个人的。在小型团队中沟通是可行的。如果落在文档上是不行的
广州-nikon(18***30) 16:40:59
文档，要有共识
张云贵(477***9) 16:45:31
就是说"草图"只用于思考和内部沟通，落到文档上必须正式建模吧。
我经常看到有开发人员面对建模工具冥思苦想，是不是借助于草图建模更能快速思考呢，相当于是建模前打草稿，这样做会不会误人呢？
梨树下(629***8) 16:46:52
对建模工具冥思苦想。就是没想法
张云贵(477***9) 16:47:27
可能考虑多了，如果多数开发人员都熟悉UML建模，自然没问题了
梨树下(629***8) 16:48:00
统一思想，需要一些时间学习。
叮叮(2*****92) 16:48:23
我现在就是这种状态 面对建模工具冥思苦想
叮叮(2*****92) 16:48:26
呵呵
叮叮(2*****92) 16:48:39
就是没还不会啊 需要学习
梨树下(629***8) 16:50:06
工具不是问题。
张云贵(477***9) 16:50:24
我们现状是多数开发人员的OO能力不够、仅把建模工具当画图板，这样一方面苦于如何建模纠结于图的细节，另一方面画出的图对设计没多少帮助
潘加宇(3504847) 21:41:23
如果你面临着开发或维护一大堆由相似的系统组成的系统家族，设计技能（OOAD）才是首要的改进点。如果一会这个项目，一会这个项目，做出来拉倒，应该先改进的是需求技能。
广州-nikon(18***30) 16:51:41
我理解，不需要所有模块都建模
广州-nikon(18***30) 16:51:45
那样成本很高
梨树下(629***8) 16:51:50
你们团队的方法。没个团队是独立，每个项目都是不一样的
广州-nikon(18***30) 16:51:56
要节选一些核心业务
广州-nikon(18***30) 16:52:27
就像一个业务系统，用户的增删改差，就没必要建模了
张云贵(477***9) 16:52:32
我的想法是针对关键部分建模，达到开发人员能理解就行，具体还需要在编码阶段细化
梨树下(629***8) 16:52:34
排定优先级。先做有价值的
梨树下(629***8) 16:53:24
核心的详细设计，其它可简单设计。
潘加宇(3504847) 21:17:15
其实不是什么图的细节，而是对背后的业务逻辑不理解。看我以往的答疑记录，许多"图的细节"背后隐含的就是领域知识的模糊，掌握严肃的建模思想可以"榨出皮袍下的小"来
潘加宇(3504847) 21:42:40
任何改进，团队的共识是必须的。没有就要建立，宁可迈得小一点，也要一起迈出去。
张云贵(477***9) 23:15:50
谢谢潘老师的指导，虽然存在更需要改进的地方（需求分析、OOAD），但那会需要更长的时间，我们先一步步来吧，谢谢。