转贴一篇CCBOY的好文——《专栏声音》转向面向对象的12个步骤

小气的神 2002-4-12

       关于转变和变化的话题我们已经讨论得不少了，不知你是否花时间考虑过这样一个问题：我们如何向一个新技术或新平台转变的问题？

       过去的技术或开发方式的转变取决于软件开发的流程和实际的设计和开发人员，往往取决于最终的开发人员，这将是对单个开发个体的考验和转变。这种情况下转变成功或失败所带来的后果基本上是这些开发人员的，职能上会有一些流到他的上一级，开发组织或公司中。不过有趣的是这种转变的过程和最后表现的形态也来得各自不同和千差万别，顺利的象滑翔飞行一样，从一个山头掠过到了另一个山顶；而痛苦的象是在泥潭中练习游泳一般，不仅满身污泥而且越游陷得越深。

今天企业级的开发需要有一个团队的协同和支撑，每个个人的力量和意志需要调整适合整个团队的主题和策略。现在一项新的技术应用在企业级开发中，也意味着整个开发团队需要一起作出反应和调整，团队中的某个人宣称开始使用某种新型技术，毫无意义。所以转向某种新的开发模型或使用新的技术成为整个开发团队需要一起面对的，甚至上延到更高的一层，项目组织或公司级的调整或改变。

当知道这个可能的事实之后，可能我们需要先接受自己的沮丧。无论如何转变的过程加长了而且变得复杂起来，个人将不再是转变的主要和唯一个体，转变不仅发生在个人而且也需要作用于整个团队，技术和非技术的东西混合在一起。

根据团队要求和所赋予的精神，这种转变的结果带来了一致性和可预测性。所以我们不会在是否要转变的问题上辩论太久，会减少用一项新技术去适应所有项目的误差，也不会贸然拿重要意义的项目去冒险体验新技术。沮丧之后我们仍然获得了团队的安慰，因为一起转变意味着共同努力形成一种良好准则。每个人能以一种客观而共识的方法来对技术本身作出评价，看它是否能接受，还是应该拒绝、或是进行调整。进而可能发展成一种机制，使技术或变革本身成为一种正面的力量被你以及团队中的大多数人控制和使用。

这里的一个关键是理解、理解还是理解，不仅个人要理解，而且整个团队也需要这种理解。我们不仅需要了解技术本身，而且还必须明白为什么使用这项技术的原因。理解到最终理解，只到形成正确的观念。理解的本身是为了获得正确而清晰的观念。

我不认为向新技术或新平台的转变可以和项目本身一起开始和发展或是交给项目管理中精良的风险控制。事实上一些项目从开始就失败了，项目本身隐藏着向新技术或新平台的转变，而整个项目组的大多数对此根本不清楚和毫无准备。失败的本身是对新技术的一项打击，因为对于局外人来说无法看到转变的工作量，而技术原因似乎更适合对于这种秘密夭折的项目作出一个可能公开的解释。

有了正确的观念和提早的意识，我们要怎样做，如何开始呢？

保守的做法是参见以前的经验和标准的规则和步骤。标准的原则象一个菜谱：“如果你想做一个蛋糕，那么首先要准备好这些这些原料，然后然后按照下面的步骤….”一本菜谱并不能够保证你一定做出一个蛋糕，因为整个过程仍然需要个人的经验、判断以及个人的感觉等等，但这总比你在房间里转来转去不知做什么要好。事实上，软件开发过程中的这种转变已不止一次发生了。下面的文章是讲述如何转向面向对象的12个步骤，我们必须相信变化中也有不变的特质，至少我们可以从中获得启发和思考。同样今天我们面临如何向WebService这样的技术或是dotNET平台等等一些新技术和平台的转变问题上不会转来转去了：）

如果说成功和失败是两条平行的直线，那么当我们拥有正确的观念和有效的原则以及策略，我们可以说我们会离成功的那一条线更近一些，离另外一条更远一些；似乎这也是我思考的最后结果了。


转向面向对象的12个步骤
Edward Yourdon & Carl Argila
<<case studies in object oriented analysis & design >>

好的管理包括告诉普通的工作人员、优秀的工作人员如何工作。
                                                 ――约翰 D。洛克菲勒

由于提交大而复杂的软件系统所造成的在预算和进度上不断增加的压力，许多公司发现他们从当前的传统的软件开发方法仓促地转向面向对象的开发模式上。正如大多数客户所证实的，转向面向对象方法时真正困难的部分是在大量的非技术方面的处理上。
       下面给出12个步骤，帮助你和你的项目转向面向对象的方法。我们不能保证这些步骤很容易实现，但如果按照这些步骤很认真地去做，那么会收到良好的效果和降低这种转变的风险。

步骤1：接受必然发生的事情
无疑以我们的观点看来在不远的将来，面向对象方法会在各种软件开发方法中占有重要的地位。
接受这些必然发生的事情，在思想上建立起正确的概念，我们认为这是通向成功的最关键的因素。参与项目的所有工作人员都应该清楚地认识到这一点，而且没有回头路可以走。我们要么就熟练地使用这些对象，要么就为时代所淘汰！
顺便提一下，这并不意味着将以前所有的东西统统抛弃。一个好的项目是建立在以前的基础上，并且将它们带向未来。

步骤2：理解，理解，理解还是理解
       在商业公司中引入任何一种新的技术时，这种技术必须能在商业上带来利益，如使产品更便宜、速度更快、性能更好等等。由此应当明白为什么要进行这种转变！
       我们不仅需要了解这种技术，还必须明白使用这种技术的原因。如果我们的目的仅仅是为了获得眼前的收益，那么最后不要使用面向对象方法。因为最后会失望的。面向对象方法所带来的收益是在下一个项目中获得的，也许可能要到下下一个项目！
       明白了面向对象方法所带来的这种变化就足够了。如果我们以前一直采用自顶向下按功能分解的方法，那么就必须弄清楚面向对象方法是一种完全不同的方法，非常非常不同。现在建立一个系统要从中间开始考虑，从对象的协同开始考虑。这能带来很大的效果，不仅仅是在系统开发上面，还在于如何组织、建立起这些系统。
       在转向面向对象方法的过程上有两种观点：一种是慢慢地逐渐演化；另一种是焕然一新的变革。必须了解究竟哪一种方法更适合自己的公司或团队。对于大多数客户来说，完全抛弃以前的所有成果而从头开始是一种愚蠢的做法。但对于有些公司，这种一步到位的变革可能更好一些。
       将上述的内容研究得再透彻一些，有助于系统地阐明在完成面向对象转换之后的去向。现在，用纸将它写下来，清晰地写下自己的打算，发给该项目的所有成员。当然，这个应当简短一些（一页或更少），这样能够让人们贴在办公室的墙上。

步骤3：先坐下来对目前阶段和境遇进行可靠的评估
现在来评估一下我们的软件开发过程。不需要正式的专业组织来，只需要看一下我们项目完成的情况。如果我们还是SEI的第一级组织，那么面向对象的转换可能会和SEI第三级的组织不大相同。
在评估软件开发过程时，很有必要对工作产品和人工制品进行标识和区分。工作产品通常是指在特定项目的里程碑日子里所应提供的可交付项或者协同活动的结果。而另一方面，人工制品不是可交付的项，通常它是由个别工作人员生成的，不是按照预定计划产生的，它仅仅是日常工作活动的结果。（例如，数据流程图、结构图、模块规格说明等等）一旦标识出所要建立的人工制品，那么就可以考虑如何使这些人工制品成为面向对象过程的一部分。
还必须对我们的人力资源进行评估。无疑人力资源是最重要的财产。在学习成功的项目组织时，Constantine和Lockwood指出“只要有优秀的人员，并为提高他们工作的生产率和质量建立良好的组织、良好的管理就能生产出最好的软件。”奇怪，真是很奇怪！究竟每个人都创造了怎样的人工制品？这种技能如何支持我们的面向对象过程呢？如何对付那些迷失的小牛呢？――那些技术上的牛仔，那些不守纪律的主角们以及任何其他自行其是的人，如何使他们适应这个过程呢？
评估完我们的资源后，最好把它写下来，拟定一个过渡计划，标识出我们的新的面向对象工作产品、标识出每个人所必须完成的支持这些工作产品的人工制品，并将这些对应到当前的过程中。

步骤4：启动一个“共生项目”（Symbioject）
       现在进入到最困难的部分类。以我们的经验来看，如果对一个新的或另外一个不同的技术各方面没有充分了解，而且在没有搞清楚它对项目、组织和人员的各种影响之前，就贸然将其应用在一个负有重要任务的项目中，这种做法是非常鲁莽的。实验性项目是学习一项新技术的最好工具，但在实现后大多数进了垃圾箱，很少实现技术转让。
       其答案就在于我们所说的“共生项目（symbioject）”一个实验性项目总是与负有重要任务的项目有着共生关系，这种关系通常表现为实验性项目是负有重要任务项目的一部分，而不是实现该项目的一个重要途径，因而可能称之为准实验性项目。而这类项目的理想时间期限是12个到18个月。

步骤5：建立有效指标进行监控
       对国防和商业软件项目的再工作（rework）寿命的研究发现一个有趣的项目成功因子。在一个成功的项目中，预期完成工作的百分比于实际完成工作的百分比之间是很接近的，这意味着成功的项目可以监控。良好的监控的关键就是我们说的“微度量”。微度量是对进度、质量、效率等进行的有效的、基于人工制品（不是基于工作产品）的度量。我们有一个同事是软件项目管理员，他认为一个好的度量是每人每个单位时间的编译请求数目，当所开发的一个模块接近尾声时这个度量的结果就应接近零。如果模块的开发过程没有遵从这个规律，就应该加以注意。在实际上这位管理人员非常擅长于此，他每天都进行编译请求的监控。
       我们发现一些好的微度量能将项目的成功和失败完全区分开来。当然项目的成功是必须使用某些微度量，而且应在这些微度量有意义的环境中使用这些微度量（这意味着你必须在你的项目中寻找和确定微度量指标来进行监控，但这些微度量并不一定是科学或某种标准定义的）

步骤6：准备使用一些花招
       啊哈，我们感兴趣的东西来了――方针策略！！！每个软件开发项目都有它既定的方针策略。但当我们转向面向对象时，这种方针策略就显得更为复杂，更为微妙。不管你是否愿意，你总是会耍一些手腕，更况且你根本无法忽视这一点。所以不妨好好设计一番。对于每种方法手段都研究一番，使其成为项目得以成功实现的因素之一。下面是我们常见的一些手段：
       尽量不要显示出你的积极主动性。（“我们无法完成 …….为什么…..为什么…..我们没有合适的CASE工具…..合适的方法…..合适的…..”）我们经常会这样说，是因为有一些研究委员会的构成是在公司级的。这个委员会的任务就是研究或制定出“十全十美”的CASE工具、方法或其他什么地。问题在于这些委员会总是在不停的研究、研究、研究….看起来他们永远不会得出合适的结论！
       另一种与上面隐藏积极主动性类似的手段就是我们通常说的心怀不满的屈从。（“你要对象？好，我就给你对象！”）这是一种更不可取得手段，因为事实上这样做的人已在不知不觉间导致了项目的失败。
       这两种手段具有同样的根源――恐惧。悲哀的是，在当今我们的软件开发团队中，所有的人不论男女，都必须是一个强者。不允许任何人说：“我害怕，我对这个对象的内容不很确信，而且我也不能保证我能学会它，能熟练运用它。我需要帮助。求求你了。”
       隐藏积极主动性和恶意屈从都不能解决恐惧。但可以将我们所使用的手段变通一下。简而言之，这个解决方法就是发现一些安全领域，并呆在这些领域中。尤其需要激发起那些逃避者的信心。通过良好的训练（这能扩大他们的安全领域）以及个别辅导（这能给他们提供安全感），他们就会成为积极的拥护者。

步骤7：关于N次幂增长的复杂性的对策
Murphy准则中有一条是：“如果两种计算机技术有相互作用的可能，那么它们就会相互作用，而且它们相互作用的方式可能是最晦涩难懂的。”我们将项目转向面向对象时，常常会引入一些其它的新技术。这些技术包括：新的平台、操作系统、数据库管理系统、体系结构、协议、国际规范、网络、程序设计语言、可能还有更多！
       每引入一种新技术、它与所有其他技术之间可能的相互作用的数量是非线性的。这个数量以N次幂增长。这种相互作用的复杂度的增长极其迅速，以致于无法集中精力做好任何事情。那么，索性就让它简单一些！我们认为，如果实在万不得以必须要在一个项目中引入一些新的技术，哪怕只有两项新技术，最好也是将它们分开引入。可能的话将它们引入并发的实验性项目中。然后在完全掌握了这些技术之后，再将它们进行集成。

步骤8：避免学习走弯路
       你是否碰到过这样的人，或许你自己也是这种的：他到一个新的城市旅游，由于太自负而不愿意问路（“我没有迷路，我知道我在哪里！”）却为了找一个地址，一个人毫无目的地在街上团团转。我们不会这么做，因为我们的生活中总免不了各种培训和咨询。但我们在试图转向面向对象时没有任何理由毫无目的地瞎转一通。成功的项目总是要借鉴其他项目的经验。
       对于一个遇到麻烦的项目进行调查时往往发现，对工作人员的培训只是给每人都买一本教科书。另外一种好的做法是先派公司中的一个人参加面向对象的培训，然后再由这个人对其他人员进行培训。在我们看来，培训和个别辅导可能是管理上最好的投资，它能保证成功地转向面向对象方法。

步骤9：为第一个信息模型寻求帮助
       如果已转而开始使用面向对象方法，但却无法为将来的重用打下基础，那么就完全失去了使用面向对象方法的意义。重用的概念很简单，而要在给定的一个应用领域中建立一个良好的可重用对象集合却是非常困难的。对象不仅要能够重用，而且还应该值得重用。它们必须能够为将来的系统打下基础，以简化将来建立系统的工作。它们还应封装一些规则和应用领域的一些约定，使得系统便于维护、支持可扩充性，并且提高重用性。
       如果不去考虑所采用的面向对象方法的特殊部分，那么就会发现所有的面向对象方法都会已这种或那种方式建立一个信息模型。这个模型生成了一个基本的对象集合。也许我们使用面向对象方法的动机各不相同，但我们认为应当对这个最初的信息模型征求他人的意见。错误的信息模型，即错误的对象集合，不可能在当时由自身显现出来。它们可能要在以后的几年中，在对系统进行修改或升级时才能被发现。

步骤10：严格遵循第一个项目的进度
       你可能会很难控制你的第一个面向对象的项目。因此我们建议必须严格遵守项目的进度。如果必要的话，你可以减小项目的范围、降低其复杂性，但千万，千万不要将项目的交付日期提前。按预计日期交出你的第一个项目完全出于士气上的考虑――这样做可以提高你的可信度，增加策略上的投资。

步骤11：开始建立可重用的类库
       尽管重用要在下一个项目（或再下一个）项目中才能体现。但现在就应该在企业的环境中建立起用于重用的最基础的机制。牢牢记住重用不是从对象开始的！而是开始于共同的约定，下一个项目将重用对象！
       环顾我们的公司，你可能会发现公司内的许多规章制度都是围绕重用。每个项目负责人的目光都集中在重用上。为了提高重用，制定许多奖励措施，例如：给对象开发人员以高报酬、给利用重用的用户以红包，以及给项目负责人员以特殊的奖励等。由此可见在公司中，重用是一个永不过时的话题，可以老生常谈。应当用有实际意义的方法对重用进行度量。对重用的分析、设计、测试、代码等所进行的度量应当包含在每个项目的重要的指标统计中。

步骤12：进行严格的事后检查和总结
       最后，在这次转变活动的总结部分，对项目中所有涉及到的部分再进行一次认真的审查和评估。什么是正确的？什么是错误的？什么是需要在下一个面向对象项目中改进？下面我们列出一些可能出现的问题：
       在完成了第一个面向对象项目后，你会发现战略上的组织结构变化都是井然有序的。你会意识到你的机构需要分成两个基本不同的组：一组是对象创建者，他们负责生产每个对象。这些人都是实现领域方面的专家。他们并不关心应当如何使用对象，他们只注重技术上的挑战。另一组是系统创建者。这些人都是应用领域方面的专家。他们侧重于理解事务过程，并集成对象协同工作，构建起一个系统。
       你将会受益于变革公司机制的要求。这种要求促使大家都要注重重用，而不是降低重用的受重视程度。显然重用的机制超越来任何一个项目或项目经理所能建立的机制。为了使重用真正的发挥作用，需要对其进行公司级的协调。这就产生了有关重用标准的需求。
       最后，你对面向对象方法的满意程度会不断地增加。你就会对自己进行下一项面向对象项目的能力充满信心。祝大家好运！



特别说明：
此文非CSDN官方专栏文章，所以文中观点只是作者本人有感而发，不代表和反映其他人观点。
本文署名原创，CSDN首发，如非经过作者授权其他人请勿用于新闻或商业用途。
引文出自《实用面向对象软件工程教程》第22章  1998.6. 电子工业出版社
如有其它疏漏不再一一注明

asp.net中文俱乐部-.net开发者世界

.NET教程面向对象编程 WEBSERVICE 教程数据库 web 代码设计开发环境 service 程序问题解决封装时间日期计算工具基础数据对象协议转贴 CCBOY

转贴一篇CCBOY的好文——《专栏声音》转向面向对象的12个步骤

TAG

Tags

精华推荐

精品下载

asp.net中文俱乐部

asp.net中文俱乐部-.net开发者世界

.NET教程 面向对象编程 WEBSERVICE 教程 数据库 web 代码 设计 开发 环境 service 程序 问题 解决 封装 时间 日期 计算 工具 基础 数据 对象 协议 转贴 CCBOY

转贴一篇CCBOY的好文——《专栏声音》转向面向对象的12个步骤

TAG

Tags

精华推荐

精品下载

asp.net中文俱乐部

.NET教程面向对象编程 WEBSERVICE 教程数据库 web 代码设计开发环境 service 程序问题解决封装时间日期计算工具基础数据对象协议转贴 CCBOY