TAO[二] .NET开发最佳实践（第一章）

第一章 模型概述

　　不知道你是否曾经设想过，让分析、设计、开发、测试以及文档编写，在同一个集成开发环境中实时同步完成？

　　我无从猜测你的想法。不过，如果你以前没有想过。那么，从现在开始，想一下如何？

　　听起来似乎不错，对吧？不过，可能实现么？

　　以前或许不可以，不过，现在，它不仅是可能的，而且是现实。这正是我在这本书中所要向你推荐的。

1 忘掉模型，我们需要什么？

　　销售员都有一个习惯，就是在向别人推销一些东西之前，总要先让人忘了这是在推销。我现在也试图让你忘掉模型，回到我们这些从事软件这行的人最根本的需求上。

　　我们一起来问一下自己，我们究竟需要什么？
1.1 从十年前开始

　　让我们回到十年前怎么样？请原谅我不能够带你回到更早的时间。因为再往前，我们是在说谎了，我接触这行，也就是十年。我是一个诚实的人。所以，我们就仅仅回到十年前，我们看看，我们这些做软件的IT人，是如何一步步提出要求，然后，另外一些IT人将它开发成工具并满足我们的需要的。

　　十年前，当时机器好象是386正是高档机器的时候。那个时候，Windows这扇窗户还没有被打开，有一个称之为DOS的操作系统正在帮助我们操作着计算机。那时候的开发，是基于过程的，一种叫做C的开发工具非常流行，如果你比我更早接触计算机，或者晚不太多的话，你一定知道Turbo C，那种只需要用两个5寸盘就可以存放的开发环境，是我个人认为DOS下编程的极品。

　　这个时候，我感到很幸福，因为我写程序的时候不使用汇编了。我记得我有一个同学用ASM写了一个打字练习程序，让我急得不行。因为同样的东西，我用C写的代码行数比他少多了（让行家见笑了，这两种语言用代码行数比较，怎么能比J）。当时，我记得我关于DOS 6.21的中断子过程，我收集了满满两大本笔记。现在还记得INT21。当时，我最想弄懂的是，为什么C&C（命令与征服的DOS版本，在486机器上，可以实现四机联网对站，在我印象中，应该是即时战略游戏的先驱之一），是如何使用到640KB之外的内存的。

　　幸福的感觉总是短暂的。慢慢地，我发现开发速度还是太慢。因为所有的东西都是过程，而我那个时候的英文就不好，一个稍微大一点的程序，为那么多函数取不重复的名字，就害了我好多时间。名称不能太长，因为那个时候没有拷贝和复制，太长了，输入是个大问题。何况名称本身有很严格的长度限制，一般要32个字符以内。

　　总之，太复杂了。不过，那个时候的我，说不清楚我要什么。在我明白如何操作640KB以外内存之前，对象来了。
1.2 对象，一个新鲜的词汇

　　在我生活中，对象最常用的场合是指男女之间的一种特殊的关系，也就是谈对象之对象。所以，我第一次听到对象这个词的时候，我理解了好一会才转过弯来。

　　记得在大二的时候，我们学校还特地组织了一次学术讲座，是关于面向对象的报告的。现在回头想想，那个报告特简单。但当时，却有当头棒喝之功效。

　　原来，我所等待的就是面向对象。

　　从而向对象时起，我终于知道，原来服务于单一对象的方法与数据可以组织在一起的，并且有属性、字段、方法、事件等等。后来，学习了C++，惭愧地是，我C学习得不错，但是，C++没有学习好，原因是，后来，我投入了Borland Delphi的怀抱了。

　　我从Delphi 3一直用到了Delphi 7，感谢Borland公司以及Delphi的设计者们，是他们让我明白了快速应用开发（RAD）是怎么回事。用于Delphi的朋友都知道，使用Delphi的感觉是：原来开发可以更轻松。

　　大学毕业之后，我参加工作，第一份工作中使用的是Delphi 3，第二份工作中使用的是Delphi 4。也就在那个时候，我对自己有了一个新的要求，这就是：
1.3 软件工程

　　软件工程化既然是我对自己的要求，当然也就是说我当时做得还不够。在上个世纪九十年代，不仅我，当时一致的看法是，我们国内的软件行业做得都不够（我现在工作于一家印度的软件公司，应该让我惭愧的是，在99年，我开始对自己提出要关注软件工程的时候，这家公司已经通过了CMM的认证）。

　　从软件开发到软件工程，是我对于自己的要求。因为我需要我写出来的代码工整、规则、出错率低。这个思想至今仍然体现在我写的每一行代码中。

　　在我只是一个软件工程师的时候，我要求自己软件要规范化，工程化。在我是一个项目经理的时候，我要求我的项目组代码规范化，工程化，直到我成为一个公司研发部的部门经理的时候，我要求我们整个部门化、规范化。让得我在做部门经理的时候，我特地为部门中的人进行了培训，整个部门写出来的代码一般，清晰。部门中的所有的同事都很开心。有些要求甚至有些过，比如强制每一个程序员都必须英文键入速度达到一定标准，同时，手指键位必须准确（但是，我后来听一个同事讲，他离开我的团队去一家新的单位面试。当他坐到电脑前，手放到键盘上，输入了几十年代码之后，几乎没有问太多的问题，他的面试就过了。也算是对我工作的一种肯定吧）。

　　我对于软件工程化的理解，也是一个过程。

　　最初局限于代码的规范化，包括注释完善等等。在这里，我要感谢我第一家工作的单位，我现在知道，在最初的工作中，能够在一家动作规范的公司中工作是多么重要。

　　后来，将其扩展到测试，慢慢地养成了在开发的同时，进行测试的习惯。测试可以是手工的，也可以是自己写一些测试代码。

　　再后来，我学会了代码检查（Code Review），我检查别人的代码，别人检查我的。

　　再后来，我写文档渐渐多了，明白了分析、设计、开发、测试、文档编写、部署及维护，即所谓的软件生命周期的东西。

　　在这个时候的我，开始主动思考我工作中需要什么？

　　我开始发现写完的分析文档，在做设计的时候并没有得到太大的重视。设计文档与代码并不一致。而最后用户文档的编写则完全是与实际开发过程分离的。这些一堆文档（通常是Word文档）最后形成了项目执行过程中的一堆废纸。

　　我那时是做企业管理应用软件的，我们在给我们的客户推销我们的产品的时候，往往说客户企业中存在着信息孤岛，那我们自己的孤岛呢？

　　那时候，我开始接触了Rational Rose，Rational RUP，Microsoft MSF等一些内容，同时参加了微软的Architect 2000的培训，以及其它一些管理方面的培训。于是隐约中，看到了一些影子。在这个时候，我想要的东西，再一次出现了，就是在最近。
1.4 模型驱动开发

　　使用过Rational Rose的朋友都知道，它有一个导出功能。可能导出代码、数据库结构等。但是，最初的时候，这方面的应用很不成熟。比如Borland的Delphi中就已经出现了代码模型的功能，我们一直都没有用过。

　　真正让模型驱动开发落到实处的，是近两年的事。这就不得不提.NET平台了。

　　.NET平台是个优秀的平台，它集成了Java平台与Delphi开发工具的优点，从而宣告了一个时候的真正开始。当然，这个时候的先行者是Java。
　　在这里，请允许我说两句题外话。是关于Java和.NET的。一家之言，用于与各位交流之用。
　　Java是一个划时代的语言，但是，为什么我不认为它是一个时代的真正的开始呢？原因很简单，Java的设计，使独立于系统（包括硬件系统及软件操作系统）平台的纯软件平台第一次出现在大众而前，在这一点上，无论用什么样的词去赞美Java，都不为过。但是，Java的致命弱点是在设计平台之初，没有考虑开发效率，更简单地说，没有为IDE的设计者留下足够的扩展空间。从其出生过程来看，它本来主要是面向网络应用的，我们都知道，就算是在现在这个时代，编写网页的老手们，也使用记事本开发。所以，集成开发环境对于Java而言，当然不是最原始的设计重点。而当后来，我们为Java赋以更多功能的时候，这个先天的不足，极大地影响了它的扩展。
　　.NET，从软件平台的概念上讲，无可争议地是继承了Java的。但是微软在设计平台之初，就考虑了对于开发工具的支持。我们回头看几年就会发现，.NET真正进入公众视野的时候，是VS.NET发布的时候。而且熟悉.NET开发的人们，也会发现，在.NET平台之上，有很多特性，简单是专门为开发工具准备的。也就是在这个时候开始，模型驱动开发，真正地走到了软件项目执行的前台。

　　我不打算将本书变为理论性的著作，所以，我并不想就模型驱动开发本身展开论述。有兴趣的朋友可以到网上去看这个主题的文章。

　　发展到这里，是否就已经满足了我的需要了呢？答案是否定的。我还有一些东西没有解决。

　　模型驱动开发，关注于分析、设计与开发部分。那么，余下的部分怎么办？也就是说，这并不完全。

　　而且，我们都知道，模型驱动开发是好，但它是概念。我们在项目执行过程中，分析文档、设计文档、软件规格说明书。这些都是必要的文档，要存档的，使用Rational XDE（假设你是使用这个工具的）之后，都是一些图形了。没有文档怎么办？

　　模型驱动开发是一个概念。当你在项目中要导入模型驱动开发的时候，你就需要知道这个概念怎么落到实处？需要什么样的工具？选择什么样的工具流程？工作中各种人员角色如何配合？工作如何衔接？相互之间的工作如何验证？

　　基于这些年，特别是最近这几年对于软件项目开发的思考，我做了一些总结，有了一个阶段性的成果，这就是
2 TAO模型

　　TAO模型，TAO源自于Tao All-in-One。在Tao All-in-One中的Tao，意指软件之道。它是我对于这些年软件项目执行的思考基础之上总结出来的一个框架。而Tao All-in-One模型，即TAO模型，则是软件之道的一个重要的组成部分。将来有机会的时候，我会继续写出软件之道其它部分的内容。

　　TAO模型的远景是：
　　使分析、设计、开发、测试、以及文档编写，在同一个集成开发环境中实时同步完成。

　　这个远景中，主要包括三个部分的内容：
2.1 完全覆盖软件研发生命周期

　　一个典型的软件生命周期包括分析、设计、开发、测试、文档，以及培训、部署与维护。

　　这里，分析、设计、开发、测试及文档编写就是所谓的软件研发生命周期，因为它是软件产品的生产过程。而培训、部署与维护则是使用研发过程的产品，为客户提供服务的过程。

　　TAO模型覆盖整个软件研发生命周期。

　　在模型驱动开发概念中，从分析起，到开发止。不包括测试及文档编写两部分。TAO模型不仅覆盖了分析、设计、开发几个部分，还包括测试及文档编写部分。
2.2 同一个集成开发环境

　　在传统的开发过程中，分析与设计是分析与设计人员运用Office软件（或者Rational Rose之类的工具）进行的，开发是使用开发工具进行的，比如Visual Studio, Delphi等。而测试是手工进行，或者开发一些小程序进行。最后，文档化由专门的角色编写。

　　而在TAO模型中，分析、设计、开发、测试以及文档编写，是在同一个IDE中进行的。在TAO模型当前的版本中，选择了Visual Studio .NET 2003进行的。
2.3 实时同步完成

　　在项目执行中，同步是一个非常重要的部分。

　　分析与设计同步：设计必须覆盖所有的需求，当需要有变化时，必须同步检查设计是否需要修正；同样地，当设计有变化时，就必须检查设计变化是否影响对于需求的实现。

　　设计与开发同步：这部分往往是最难的，也是我们在日常工作中最难做到的。原因是分析与设计可能是由同一个人完成的，同步起来容易一些。而开发与设计往往不是同一个人完成的，所以，它们之间的同步，往往涉及到一些平衡与争论。而往往因为设计人员有时不懂得开发技术，当代码中有不一致时，往往很难发现（这也是为什么国内基本上都是开发技术高手做分析文档的原因）。

　　其它同步还包括分析、设计、开发与测试的同步。当分析分析文档发生变化时，系统测试案例就必须同步发生变化。当设计文档发生变化时，单元测试案例就必须发生变化。

最后，也是最难的，就是各部分与文档的同步。往往出于交货压力等原因。写文档，被认为是最没有必要的一部分：系统都完成了，怎么能因为文档没有写好，而影响交货期呢？

　　而软件工程的基本要求就是各部分必须互相验证，保持一致。也就是说，任何一个环节有变化，所有的其它环节受影响的部分必须同步发生变化。
3 TAO模型的特点
3.1 TAO模型是一个实践模型，而非理论模型

　　在远景中，一个贯穿的思想就是，该模型必须能够直接用于实践，使得在应用中，你所在的项目，能够直接实现分析、设计、开发、测试及文档编写的同步。

　　与其它模型不同在于：很多模型提出了很好的概念，这些概念非常先进，以致于一时无法应用到实践。而TAO模型它本身就是一个实践模型，是可以直接运用于实践的模型。

　　TAO模型是一个经过实践项目检查过的模型。我本人负责的项目，是在严格按照CMM3的标准基础上执行的。在项目执行过程中，应用了该模型。

　　作为模型的设计者，最开心的事就是你能够在阅读完本书后，发现TAO模型好用、实用，并且将其引入到你的项目中去。如果你这方面的打算，请写信告诉我。如果你发现该模型在实践中有无法实施的情况，也请写信与我联系，我们一起讨论改进方案。这也是TAO模型的持续改进之路。
3.2 TAO模型是一个动态模型，而非静态模型

　　我们都知道，在项目执行过程中，每时每刻，项目的状态都在发生着变化。而作为指导项目执行的模型，它就必须适应这种变化。

　　从TAO模型的远景定义中，就可以看出，TAO模型是一个动态模型。它强调的是在变化的过程中的实时同步。也就是说，在任何变化发生，而引起项目执行中的某一部分发生变化时，各部分紧跟着发生变化，并在自动同步，以达到稳定状态。

　　比如，当需求发生变化，首先反映在项目的分析文档上，在TAO模型中，分析文档的变化，直接映射到软件的设计上，设计上需要改变的部分实时显现出来。于是，设计人员立即定位出设计需要更新的部分，这时，需求得到了设计上的满足，而开发人员又得到提醒，相应需要修改的部分也被明确指出。类似的，测试案例也被自动要求更新。当这一切完成之后，文档自动同步。项目达到了一个新的同步平衡点。
4 如何阅读本书

　　本节内容将帮助你更好、更方便地阅读本身。作为作者，当然希望你能够有兴趣将整本书读完。不过，我自己读书的经验告诉我，对大部分人来说，这很难做到。如果我是读者，我更希望我能够非常方便地找到我所感兴趣，以及我需要了解的内容。

　　在本节中首先介绍一个书的组织结构，然后，再根据您的角色，给出阅读建议。
4.1 书的组织结构

　　全书分为三个部分：准备知识、过程实践以及阅读材料。

　　准备知识包括本书的1至3章，分别是模型概述，项目管理框架，以及案例介绍。

　　模型概述，也就是本章的内容，主要包括对于模型来历的一些描述，以及模型的远景及特点的介绍。当然，还有就是本节的关于如何阅读本书的一个指导。

　　而项目管理框架是一个非常重要的章节，我们都知道项目的执行都离不开管理的支持。在这一章中，重点讲述了项目执行的过程模型及组织模型。

　　接下去的一章就是案例介绍。既然TAO模型是一个实践模型，那就应该将其放到一个实际的项目中去介绍。在案例介绍一章，我将给出一个完全的项目的项目陈述。而在第二部分中，将会完整地介绍如何在TAO模型下去实现这个系统。

　　第二部分是项目执行框架，将按照软件生命周期的顺序，结合具体的案例，去展开TAO模型的具体内容。正如你在TAO模型的远景定义中所得到的信息一样，第二部分的在章节安排上是按照一般的分析、设计、开发、测试、文档编写的顺序排的，但，你会发现在实际的工作中，这些是有交叉的。

　　在分析、设计、开发、测试、文档编写各章节之后，有一个专业的章节用于讲述如何在变化中取得实时同步。
4.2 本书的适用对象

　　我很想说本书适合所有读者，但坦白说，如果我真的那样讲了，我自己都不会相信。不过，还好，经过与一些朋友的讨论之后，我发现本书适合的人群还是挺多的。不过，并不是所有的人都需要完整地读完本书。我是根据读者所被赋以的职责来划分人员的。
　　项目管理人员

　　这部分读者可能的职务名称为首席技术官司、技术总监、项目经理，或者是QA、CMM等。我猜你们关心的是TAO模型是什么？它有什么用？如果我猜中了，那么，我建议你读完本章之后，再读了一下项目管理框架一章。然后，再看一下变更管理一章。
　　项目执行人员

　　这部分读者可能的职务名称为系统分析员、高级软件工程师、软件工程师、测试工程师等。我猜你们重点感兴趣的是，如果所在的项目真的要导入TAO模型，你们要做些什么？与以往的工作有何不同？我建议你人阅读第一部分的所有章节。然后，在第二部分阅读与你工作相关的章节以及变更管理一章。当然，其它章节，我推荐你也看一下。因为在TAO模型中，各个部分都有你的参与。
　　项目管理研究人员

　　如果你像我一样，对于项目执行与项目管理的方法论感兴趣，那么，我建议你阅读本章以及第二章。然后，其它各章根据你自己的兴趣，选择性的阅读。可以结合你这些年的工作经验与体会，以及研究心得，看看相应部分与你所想的有何不同。我更希望你在发现有所不同的时候，能够将这些不同，写信告诉我。
　　对本文感兴趣的其它人员

　　我知道穷举法是很危险的，因为很难用证明我的穷举已经列举了全部。如果你恰好不认为你自己属于上面三类人中的任何一类。那就归于此类吧。我基本上无从猜测你的兴趣点在哪里。不过，还是给你一些引子。你或许应该先看一下本章的4.1小结，了解一下书的结构，希望那里的结构能够对你有一些帮助。

　　曾经有朋友在看完样稿之后，跟我开玩笑说，你需要将这本书写得简单一些，尽可能用常用字，他好拿来教公司的外国同事学习汉字。我给我这位朋友的建议是：带你的同事从各章的标题看起，从第一章开始。第一章标题中认一，第二章标题中认二。他们一定很快会猜出第三章中应该有什么了。这就是举一反三。