071223培训心得

 

         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 ．重构、重写与重载

         讲师标榜微软从来不做重构，只是在原有的代码基础上增加一个。如果没有良好的拓展结构，如何做到重载？

         因此我很同意：讲师可以很看不起那些做重构的人，因为他的程序结构一次成型，结构良好，无需重构。而我们达不到这样的境界，还是得从重构开始。

        

评论

1 楼 xiaoZ5919 2009-03-05  

引用

   因此我很同意：讲师可以很看不起那些做重构的人，因为他的程序结构一次成型，结构良好，无需重构。而我们达不到这样的境界，还是得从重构开始。

严重同意！