仁达华 2018-11-5 10:37
老师，分析做到什么详细程度呢，好像要花很多工作量而且还做不好。
潘加宇：
分析的详细程度：【尽力】把【当前用例所需要的】核心域知识展示出来，包括类图、序列图和状态机图。
注意括起来的重点。
开发是增量迭代式进行的，每次只思考当前最值得履行的需求。分析的工作量并不大。
也许为了解决此需求，需要添加一些类，也可能不需添加只需要修改一些类，甚至不用修改，原有的类已经可以满足。如果是速度、并发容量等质量需求，那就和分析（核心域建模）没有关系了。
也并不要求分析到毫无遗漏，只要尽力，就尽可能减少了后面的风险以及提高编码的效率。就像考试一样，不一定考100分，只要比竞争对手，比过去的自己考得好就可以了。
之所以难做到，通常有以下误解：
（1）以为可以逃避，所以不去掌握应有的建模技能
分析的环节是逃不掉的。核心域逻辑没想清楚就直接去编码，逻辑并不会从天上掉下来，只能在编码时慢慢脑补，效率并没有提高。例如，类的状态变化，如果用层次化形象化的状态图表达你都没理清楚，编码的时候对着线性的文本介质灵光反而能够从天而降？很多时候只是无可选择地硬着头皮敲一些东西，不管是对还是错，因为箭在弦上已经不得不发了，赶紧行动起来，掩盖自己的无能。
所谓结对编程，只不过把一个人脑补变成两个人脑补而已。虽然俗话说"三个臭皮匠，胜过一个诸葛亮"，但是俗话很多是错误的。三个臭皮匠还是臭皮匠，没有掌握应有的技能就是解决不了问题，不会胜过诸葛亮。三个臭皮匠更多的结局是会把诸葛亮像布鲁诺那样烧死，口号可能是"过度设计"，谁他妈让你这么聪明呢。
我根本不会"设计"也不学习"设计"，所以就不会"过度设计"，这样就避免了陷入"过度设计"的陷阱。"知识越多越反动"！这些做法背后都能找到西方白左民粹主义的思想根源。
对此的进一步阐述，参见《软件方法》第8章。电子版下载： http://www.umlchina.com/book/softmeth0809.pdf
（2）混淆"详细"和"全面"
有的开发人员没有掌握应有的建模技能，无法详细描述应该描述的核心域逻辑，干脆用"全面"来遮掩。例如酒店当前需要解决的是客房方面的问题，本应该好好地对客房这个子域建模，但因为没有掌握相应技能，只好泛泛而谈，然后把餐饮、娱乐、营销等子域拉进来充数。