《Head First OOA&D》读书笔记(1)-软件开发流程概要

   最近在学习关于OOD&A 方面的知识，引用下面的一些文章，作为学习的入门

 

   文章引自：http://www.cnblogs.com/lihongchao/archive/2008/01/12/1036586.html

软件开发流程概要(1)-《Head First OOA&D》读书笔记

        最近受了点刺激开始系统的找些软件开发过程管理书籍来看, 我的这篇Blog 记录了一些. 最近又买了邹欣的《移山之道》, 本来是很少买国内著作的书, 但愿这本能让国内的程序员有所收获. 其实这些书籍并不是太适合工作六七年的人来看了，但我的一个毛病就是求全责备，尽最大可能解决我在软件开发过程中遇到的每一个疑惑，能够为每一个实践行为找到理论依据和存在的原因。这本书是我继《Head First Design Pattern 》之后读得第二本Head First 系列书籍，我感觉很适合我的，因为通篇文字不多，用了大量的表格，图画来解释一些OO 的基本概念，因此我只用了大约一个月的空闲时间就读完了这600 页的书（包括前言 J ）. 其实所有的内容基本都是有了解的，哪我的收获在哪里呢？收获就在知道了为什么以及怎样组织我们以前看到的，用到的这些技术，概念比如：OO Principles, Test Driven, Domain Analysis, Use Case, Unit test, Requirement Analysis  等等

      这里我打算把书中的软件开发的流程概要介绍一下，以后有时间我会陆续把每一个开发中的主要环节都展开一下。先看书中的一个图（手机拍的，多包涵）：

    基本上就是这么一个流程，但是并不是说从第一部Feature List 开始一直做到最后一步Delivery就把系统开发完了，因为大家也都知道实际中哪有这么容易的事情，很多步骤都是要做好几次，甚至要反复的来做。但对于一个具体的问题基本都是按照这个顺序来解决的。

1.       Feature List 和Use Case Diagrams。基本来说，需求分析总是解决一个问题的第一步，因为不确定问题是什么，肯定是没法解决的。所以这一步很关键，也很容易。关键是说准确的需求能够使开发过程非常顺利，想法不明确，经常变化的需求对于开发团队是很大的挑战。容易是说，这是开发的第一步，没有哪个项目再这个步骤失败。这个步骤一般都是能够完成的。
    说了这么多那需求的第一步是什么呢？典型的场景就是，客户会给你一个一页纸的所谓需求文档（当然成熟的客户会给两页纸的文档）。其实这几页纸只能说是愿景（Vision），只是参考这个文档，很难界定清晰的需求。所以需求的第一步要么是确定功能列表（Feature List），要么是得出用例图(Use Case Diagram)，注意用例图只是分辨出各个用例，比具体用例的颗粒度要大。无论做哪一个都无法用这一页纸来得出准确的答案。怎么办呢，交流！对，不断的和用户交流，界定清楚各个主要的Feature和主要的用例，尽可能的准确界定系统需要做到的，实现的功能。不必追求一次得到完整的列表或用例，随着迭代次数的增加，自然会得到完善的。这样你就清楚了，系统需要做些什么以及用户会如何使用这个系统。

2.       Break Up the Problem。大体知道了要做些什么功能。就要把这些功能按照相互关系进行分类，也就是把系统分成几个模块，尽量使模块之间的交互减少，接口清晰。这里就需要应用像封装，单责任原则等OO的一些设计原则了。一个系统特别是规模比较大的系统如果有科学的模块划分，能够很大程度上提高并行开发的效率，减少由于某个模块交付延期对于其他模块的影响。

3.       Requirement。看图上就知道，开始选择某个功能或用例进行开发之前，还要有一步，Understand the Problem。也就是能够对于问题有准确的理解，然后需要再次和用户的交流，进行针对某个细化用例或功能的分解。这里就有两种开发模式了,功能驱动(Feature Driven)或是用例驱动（Use Case Driven）。功能驱动开发颗粒度比用例驱动要小一些。选择哪一种路径决定下一步得到什么。选择用例驱动呢，就要写用例(Use Case),用例可能有很多种表现形式，用例图，自然语言描述，步骤分解等。最终都要把主要路径，其他路径都能包括进来，也就是各种场景(Scenario)都要包括。用例的用处是为了和用户进行交流，以用户熟悉的方式，确认我们对于需求的理解是正确的，完整的。第一次迭代时，功能点或用例的选取就要找最根本的，最核心的，被别的部分依赖最多的一个来开始进行开发的迭代。

4.       Domain Analysis 和Design。领域分析是指把用例中名词和最终系统中的实体类进行映射，动词和方法进行映射。当然这种映射没有一一的对应关系，需要根据具体情况进行增加或是删除，修改。最终把这些类和方法组装成类图(Class Diagram)。类图是软件开发中一个关键的中间产品，能够让其他关心你系统的程序员快速的对系统架构有整体的了解。所说的系统设计也就是参照实际情况，以及一些设计原则，设计模式，对类图上的各个类进行分解，组合，抽象，细化等操作。一个结构合理，功能清晰，兼顾维护性和扩展性的类图对于后续开发工作的贡献是不言而喻的。

5.       Implementation。实现看起来只是参照类图和其他的现有代码，进行一些类似砌砖头一样的工作。其实，实现的工作远远不止如此。首先，需要有良好的代码风格，使代码有可读性。其次，要有足够的单元测试保证，现在测试驱动(Test Driven)已经非常受重视。第三，要有代码重用考虑，能够最大限度的采用已有方法或算法进行功能实现。第四，要有随时重构(Refactoring)的意识,以保证代码能够在不断增长的过程中保持简洁，高效，可读，可维护，可扩展，能够重用。最后，就是要对于OO的基本规则有切合实际的应用，比如OCP,SRP,DRY等这些规则。

6.       Iteration. 一般是实现完一个功能或是用例之后，再选取另一个功能或用例应用前几个步骤进行迭代的开发，知道所有的功能或用例全部实现。其中也可能会不时的对系统的功能列表，用例图进行修改，更新。也就需要和客户有通畅，清晰的沟通，保证所开发的系统就是用户所想要的。

7.       Delivery. 交付，有了以前的这些步骤的保证，最终的交付是一件非常值得期待的事情。客户会发来感谢邮件，老板会准备可观的红包，自己也非常有成就感，休假…

这些就是一个开发过程的简要介绍，我计划下一篇能够深入的介绍需求的获取和分析，以及和用户的有效交流。