关键词：
《构建之法》阅读笔记（3）
两人合作、团队和流程
代码风格的原则：简洁，易读，无二义性
代码复审的目的不只在于指出代码的错误，还在于发现逻辑错误、算法错误、潜在的错误和回归性错误——当前的修改导致以前修复的缺陷又重新出现、可能需要改进的地方，还可以互相传授经验、让更多的成员熟悉项目各部分的代码、同时熟悉和应用领域相关的实际知识。
二人合作的阶段分为：萌芽阶段、磨合阶段、规范阶段、创造阶段、解体阶段。在二人合作阶段，每个人都有自己的看法与观点，会有很多问题出现，要知道，问题早出现比晚出现要好得多，需要理性思考来获取合适地方法。
从瀑布模型开始的各种模型都有一个共同点：重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一流程（Rational UnifiedProcess，RUP）。RUP把软件开发的各个阶段整合在一个统一的框架里
要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程（Discipline）或者工作流（Workflow）。简介如下
业务建模
用户提供软件，就要理解目前用户的业务流程，但是精通计算机语言细节的工程师并不能马上理解对用户活动和期望值的各种自然语言描述。为了解决这个问题，业务建模（Business Modeling）工作流用精确的语言（通常是UML）把用户的活动描述出来。这个词有时也翻译为“商业建模”，但并不是只有存在金钱交易的商业活动才能符合建模的要求，任何和客户的正常工作相关的业务活动（例如政府为居民提供网上服务，学生到图书馆借书）都是建模的对象。这个工作流的结果通常是用例（Use Case）
需求
有了用例之后，开发人员和用户（或者用户代表）要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件，如何验证功能满足了用户需求。这就是需求（Requirement）工作流的作用
分析和设计
分析和设计（Analysis & Design）工作流将需求转化成系统的设计。这一步结束之后，团队成员就能知道系统有哪些子系统、模块，它们之间的关系是怎样的
实现
在实现（Implementation）工作流中，工程师按照计划实现上一步产出的设计，将开发出的组件（Module），连同验证模块（例如：单元测试）提交到系统中。同时，工程师们集成由单个开发者（或小组）所产生的结果，通过手工或自动化的手段，把可执行的系统搭建出来
测试
测试（Test）工作流要验证现阶段交付的所有组件的正确性、组件之间交互的正确性，以及检验所有的需求已被正确地实现。在这个过程中，发现、报告、会诊、修复各种缺陷，在软件部署之前保证质量达到预期要求
部署
部署（Deployment）工作流的目的是生成最终版本并将软件分发给最终用户。具体过程可以参考“典型用户和场景”一章
配置和变更管理
配置和变更管理工作流（Configuration andChange Management）负责管理RUP各个阶段产生的各种工作结果（例如源代码控制系统管理和备份各种源文件），要记录修改人员、修改原因、修改时间等属性，有些团队还可以考虑并行开发、分布式开发等
项目管理
软件项目管理工作流（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品
环境
环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。RUP把软件开发分成几个阶段，一个大阶段的结束称为一个里程碑（Milestone），每个阶段内可以有几个迭代，以比较灵活的形式实现本阶段的任务。从这一点来说，RUP在大尺度上像瀑布模型，在每个阶段内像迭代模型
下面是RUP四个阶段的介绍：
初始阶段——此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里（我们的系统究竟和什么别的外部实体打交道），大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标（LifecycleObjective）里程碑
细化阶段——它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段结束时，项目到达了第二个重要的里程碑：生命周期结构（Lifecycle Archi-tecture）里程碑
构造阶段——在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。此时的产品版本也常被称为“beta”版
交付阶段——这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代（beta1，beta2等），基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑
构建之法阅读笔记04
好久没更新《构建之法》了，不是没读，主要是读的入神，顾不过来写阅读笔记了，嘻嘻，废话不多说，分享下自己的阅读体会吧·····o(^▽^)o 本期主要说，... 查看详情
构建之法阅读笔记
构建之法阅读笔记（1）这周我开始了我的阅读之路，阅读了构建之法的第一二章。构建之法的第一章讲的是软件和软件工程是什么:软件=程序+软件工程。我一开始对软件工程的理解就是敲代码，写程序，其实，事实不是这样，... 查看详情
构建之法阅读笔记01
构建之法读后感01 查看详情
构建之法阅读笔记04
构建之法阅读笔记04 &nbs 查看详情
构建之法阅读笔记02
构建之法阅读笔记02 &nbs 查看详情
构建之法阅读笔记03
构建之法阅读笔记03 &nbs 查看详情
构建之法阅读笔记05
构建之法阅读笔记05 &nbs 查看详情
构建之法阅读笔记02
构建之法阅读笔记02 &nbs 查看详情
构建之法阅读笔记05
构建之法阅读笔记05 &nbs 查看详情
构建之法阅读笔记04
构建之法阅读笔记04 &nbs 查看详情
构建之法阅读笔记01
...bsp; 经过了三天的粗略阅读，我对<<构建之法>>这本书有了一定的了解。本书采用幽默风趣的语言，使软件工程的相关知识易于理解。在阅读之余我提出了一些问题。 1.杀毒软... 查看详情
构建之法阅读笔记01
《构建之法》这本书从我最开始阅读的地方开始就在强调，“learningbydoing”这一点跟我们以前学习中的老师主要为我们讲解理论知识的传统观念有些不同，这本书强调的是让学... 查看详情
《构建之法阅读笔记02》
这次主要对《构建之法》的第四章“两人合作”作一次阅读笔记。首先是代码规范问题。我过去对于代码规范问题并没有做到注意。在编程中，许多变量和函数的命名都非常的简单而没有实际的意义。而且编程时不注意对... 查看详情
《构建之法》阅读笔记02
上一篇的阅读笔记是粗略地读一下所写的阅读笔记，提出了十个问题；而这一次是对具体的第四章所精度后的阅读感受。 第四章的主要内容是两人合作，在这里面就不得不提到我们的代码格式... 查看详情
《构建之法》阅读笔记
《构建之法》第一章阅读笔记大马哈鱼洄游模型软件工程按照经典的瀑布模型 1.需求分析 2.设计阶段 3.实现阶段 4.稳定阶段 5.发布阶段 6.维护阶段事实上在现实世界中，软件工程师的职业发展与瀑布流程刚... 查看详情
《构建之法》阅读笔记
《构建之法》阅读笔记（3）两人合作、团队和流程代码风格的原则：简洁，易读，无二义性代码复审的目的不只在于指出代码的错误，还在于发现逻辑错误、算法错误、潜在的错误和回归性错误——当前的修改导致以前修复的... 查看详情
构建之法阅读笔记
这周通过阅读构建之法，知道了MSF的原则，团队模型，开发模式.基本原则：1.推动信息共享与沟通2.为共同的远景二=而工作3.充分授权和信任4.各司其职，对项目共同负责5.交付增量的价值6.保持敏捷，预期和适应变化7.投资质量8.... 查看详情
《构建之法》阅读笔记
《构建之法》阅读笔记（4）需求分析软件的需求主要可以通过以下步骤来获取：（1）获取和引导需求；（2）分析和定义需求；（3）验证需求；（4）在软件产品的生命周期中管理需求。对软件的需求，可以从不同角度来划分：... 查看详情