当前位置：编程学习 > C#/ASP.NET >>
答案：
小气的神 2002-4-12
关于转变和变化的话题我们已经讨论得不少了，不知你是否花时间考虑过这样一个问题：我们如何向一个新技术或新平台转变的问题？
过去的技术或开发方式的转变取决于软件开发的流程和实际的设计和开发人员，往往取决于最终的开发人员，这将是对单个开发个体的考验和转变。这种情况下转变成功或失败所带来的后果基本上是这些开发人员的，职能上会有一些流到他的上一级，开发组织或公司中。不过有趣的是这种转变的过程和最后表现的形态也来得各自不同和千差万别，顺利的象滑翔飞行一样，从一个山头掠过到了另一个山顶；而痛苦的象是在泥潭中练习游泳一般，不仅满身污泥而且越游陷得越深。
今天企业级的开发需要有一个团队的协同和支撑，每个个人的力量和意志需要调整适合整个团队的主题和策略。现在一项新的技术应用在企业级开发中，也意味着整个开发团队需要一起作出反应和调整，团队中的某个人宣称开始使用某种新型技术，毫无意义。所以转向某种新的开发模型或使用新的技术成为整个开发团队需要一起面对的，甚至上延到更高的一层，项目组织或公司级的调整或改变。
当知道这个可能的事实之后，可能我们需要先接受自己的沮丧。无论如何转变的过程加长了而且变得复杂起来，个人将不再是转变的主要和唯一个体，转变不仅发生在个人而且也需要作用于整个团队，技术和非技术的东西混合在一起。
根据团队要求和所赋予的精神，这种转变的结果带来了一致性和可预测性。所以我们不会在是否要转变的问题上辩论太久，会减少用一项新技术去适应所有项目的误差，也不会贸然拿重要意义的项目去冒险体验新技术。沮丧之后我们仍然获得了团队的安慰，因为一起转变意味着共同努力形成一种良好准则。每个人能以一种客观而共识的方法来对技术本身作出评价，看它是否能接受，还是应该拒绝、或是进行调整。进而可能发展成一种机制，使技术或变革本身成为一种正面的力量被你以及团队中的大多数人控制和使用。
这里的一个关键是理解、理解还是理解，不仅个人要理解，而且整个团队也需要这种理解。我们不仅需要了解技术本身，而且还必须明白为什么使用这项技术的原因。理解到最终理解，只到形成正确的观念。理解的本身是为了获得正确而清晰的观念。
我不认为向新技术或新平台的转变可以和项目本身一起开始和发展或是交给项目管理中精良的风险控制。事实上一些项目从开始就失败了，项目本身隐藏着向新技术或新平台的转变，而整个项目组的大多数对此根本不清楚和毫无准备。失败的本身是对新技术的一项打击，因为对于局外人来说无法看到转变的工作量，而技术原因似乎更适合对于这种秘密夭折的项目作出一个可能公开的解释。
有了正确的观念和提早的意识，我们要怎样做，如何开始呢？
保守的做法是参见以前的经验和标准的规则和步骤。标准的原则象一个菜谱：“如果你想做一个蛋糕，那么首先要准备好这些这些原料，然后然后按照下面的步骤….”一本菜谱并不能够保证你一定做出一个蛋糕，因为整个过程仍然需要个人的经验、判断以及个人的感觉等等，但这总比你在房间里转来转去不知做什么要好。事实上，软件开发过程中的这种转变已不止一次发生了。下面的文章是讲述如何转向面向对象的12个步骤，我们必须相信变化中也有不变的特质，至少我们可以从中获得启发和思考。同样今天我们面临如何向WebService这样的技术或是dotNET平台等等一些新技术和平台的转变问题上不会转来转去了：）
如果说成功和失败是两条平行的直线，那么当我们拥有正确的观念和有效的原则以及策略，我们可以说我们会离成功的那一条线更近一些，离另外一条更远一些；似乎这也是我思考的最后结果了。
转向面向对象的12个步骤
Edward Yourdon & Carl Argila
<<case studies in object oriented 易做图ysis & design >>
好的管理包括告诉普通的工作人员、优秀的工作人员如何工作。
――约翰 D。洛克菲勒
由于提交大而复杂的软件系统所造成的在预算和进度上不断增加的压力，许多公司发现他们从当前的传统的软件开发方法仓促地转向面向对象的开发模式上。正如大多数客户所证实的，转向面向对象方法时真正困难的部分是在大量的非技术方面的处理上。
下面给出12个步骤，帮助你和你的项目转向面向对象的方法。我们不能保证这些步骤很容易实现，但如果按照这些步骤很认真地去做，那么会收到良好的效果和降低这种转变的风险。
步骤1：接受必然发生的事情
无疑以我们的观点看来在不远的将来，面向对象方易做图在各种软件开发方法中占有重要的地位。
接受这些必然发生的事情，在思想上建立起正确的概念，我们认为这是通向成功的最关键的因素。参与项目的所有工作人员都应该清楚地认识到这一点，而且没有回头路可以走。我们要么就熟练地使用这些对象，要么就为时代所淘汰！
顺便提一下，这并不意味着将以前所有的东西统统抛弃。一个好的项目是建立在以前的基础上，并且将它们带向未来。
步骤2：理解，理解，理解还是理解
在商业公司中引入任何一种新的技术时，这种技术必须能在商业上带来利益，如使产品更便宜、速度更快、性能更好等等。由此应当明白为什么要进行这种转变！
我们不仅需要了解这种技术，还必须明白使用这种技术的原因。如果我们的目的仅仅是为了获得眼前的收益，那么最后不要使用面向对象方法。因为最后会失望的。面向对象方法所带来的收益是在下一个项目中获得的，也许可能要到下下一个项目！
明白了面向对象方法所带来的这种变化就足够了。如果我们以前一直采用自顶向下按功能分解的方法，那么就必须弄清楚面向对象方法是一种完全不同的方法，非常非常不同。现在建立一个系统要从中间开始考虑，从对象的协同开始考虑。这能带来很大的效果，不仅仅是在系统开发上面，还在于如何组织、建立起这些系统。
在转向面向对象方法的过程上有两种观点：一种是慢慢地逐渐演化；另一种是焕然一新的变革。必须了解究竟哪一种方法更适合自己的公司或团队。对于大多数客户来说，完全抛弃以前的所有成果而从头开始是一种愚蠢的做法。但对于有些公司，这种一步到位的变革可能更好一些。
将上述的内容研究得再透彻一些，有助于系统地阐明在完成面向对象转换之后的去向。现在，用纸将它写下来，清晰地写下自己的打算，发给该项目的所有成员。当然，这个应当简短一些（一页或更少），这样能够让人们贴在办公室的墙上。
步骤3：先坐下来对目前阶段和境遇进行可靠的评估
现在来评估一下我们的软件开发过程。不需要正式的专业组织来，只需要看一下我们项目完成的情况。如果我们还是SEI的第一级组织，那么面向对象的转换可能会和SEI第易做图的组织不大相同。
在评估软件开发过程时，很有必要对工作产品和人工制品进行标识和区分。工作产品通常是指在特定项目的里程碑日子里所应提供的可交付项或者协同活动的结果。而另一方面，人工制品不是可交付的项，通常它是由个别工作人员生成的，不是按照预定计划产生的，它仅仅是日常工作活动的结果。（例如，数据流程图、结构图、模块规格说明等等）一旦标识出所要建立的人工制品，那么就可以考虑如何使这些人工制品成为面向对象过程的一部分。
还必须对我们的人力资源进行评估。无疑人力资源是最重要的财产。在学习成功的项目组织时，Constantine和Lockwood指出“只要有优秀的人员，并为提高他们工作的生产率和质量建立良好的组织、良好的管理就能生产出最好的软件。”奇怪，真是很奇怪！究竟每个人都创造了怎样的人工制品？这种技能如何支持我们的面向对象过程呢？如何对付那些迷失的小牛呢？――那些技术上的牛仔，那些不守纪律的主角们以及任何其他自行其是的人，如何使他们适应这个过程呢？
评估完我们的资源后，最好把它写下来，拟定一个过渡计划，标识出我们的新的面向对象工作产品、标识出每个人所必须完成的支持这些工作产品的人工制品，并将这些对应到当前的过程中。
步骤4：启动一个“共生项目”（Symbioject）
现在进入到最困难的部分类。以我们的经验来看，如果对一个新的或另外一个不同的技术各方面没有充分了解，而且在没有搞清楚它对项目、组织和人员的各种影响之前，就贸然将其应用在一个负有重要任务的项目中，这种做法是非常鲁莽的。实验性项目是学习一项新技术的最好工具，但在实现后大多数进了垃圾箱，很少实现技术转让。
其答案就在于我们所说的“共生项目（symbioject）”一个实验性项目总是与负有重要任务的项目有着共生关系，这种关系通常表现为实验性项目是负有重要任务项目的一部分，而不是实现该项目的一个重要途径，因而可能称之为准实验性项目。而这类项目的理想时间期限是12个到18个月。
步骤5：建立有效指标进行监控
对国防和商业软件项目的再工作（rework）寿命的研究发现一个有趣的项目成功因子。在一个成功的
