23号参加了1天的架构师培训，培训的唯一收获是：这样的讲师也敢出来混，而且价格不菲。在他的讲演中，我不时的“出离愤怒”，也就明白了为什么会有人在他的课程上对他人身攻击。下面列出对我们的五大误导：
1．软件过程方法论与项目生命周期
在屏幕上列出MSF、RUP、CMMI、XP和Agile后，讲师提问“哪个是最接近瀑布模型的？”，随后自己答曰“RUP，是文档最多，最接近瀑布模型”。
讲师一厢情愿的对IBM充满憎恨，是否真的了解过RUP，他是否了解OOAD。我们知道创建UML的三个人，有两个现在IBM做Rational。
2．愿景、口号与系统目标
MSF强调愿景，在第一个阶段就明确规定了“确定愿景”这个环节。
Chen同学提“随时随地可以订餐”被讲师批为口号。讲师说愿景应该是“两年内营业额翻一番”，应该是“每个人桌上都有一台PC”。这些与口号有什么区别？
讲师说在区分是否重要工作时，拿愿景比一下就可以。
OOA同样重视愿景，并对愿景有严格的要求：真实并且可以度量。度量的结果就是系统目标（还有一部分非系统完成的），接下来所有的工作都紧紧围绕在这些系统目标上。在需求获取阶段，目标与用例构成二维检查表，以检查是否所有的目标都有用例覆盖，是否所有识别的用例都符合这些目标。
在区分工作时，如何用口号样的愿景作为划分尺度，凭感觉么？
3．功能需求与非功能需求
讲师说用Use Case搜集功能需求，非功能需求需要另外收集。这个是最令人气愤的误导。
如果使用OOA，则需要以用例为核心组织所有的需求，所有的需求即包括来自客户的业务需求、非功能性需求，也包括来自所有涉众的需求与要求，比如银行卡为什么需要密码，而密码为什么只有6位。涉众利益在步骤中得到体现。
参考下图：
非功能需求包括：可用性、可靠性、可支持性和性能。只有能够度量的需求，才能够被实现。比如，在可用性方面如果客户提“系统应该非常好用”，这不是一个需求，或者不是一个可以实现的需求，我们必须将其转化为如“第一次使用时30分钟内能学会管理图书模块”，或者“5次击键能完成图书录入，不需要使用鼠标”。
4．Use Case的粒度
Use Case不存在粒度问题，并不是像讲师说的那样可以划分到最细粒度。这个是OOA初学者常犯的错误。
首先，提出Use Case方法的是为了试图解决需求的易变和难以捕获，通过合理的程序结构来解决易变，这就是为什么OO有这么多的层，有这么多的模式；通过用户观点以来捕捉需求。因此，Use Case是以用户观点看问题，而不是系统观点或程序员观点。
其次，在RUP中Use Case的定式是“用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例”。“价值结果”是对执行者来说有意义的目标。“执行者可见”是指业务语言而非技术语言，使用用户观点而非系统观点。
最后，用例表征系统使用复杂度，与系统内部复杂度无关。我们常见的粒度问题有：把步骤当用例；使用CRUD最为用例（CRUD是系统观点，而非用户观点）。
5．重构、重写与重载
讲师标榜微软从来不做重构，只是在原有的代码基础上增加一个。如果没有良好的拓展结构，如何做到重载？
因此我很同意：讲师可以很看不起那些做重构的人，因为他的程序结构一次成型，结构良好，无需重构。而我们达不到这样的境界，还是得从重构开始。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图