敏捷开发 之 计划测试 与 重构

Posted 2020-08-02 stone lv

本系列内容为 Robert C. Martin 敏捷开发一书的读书笔记， 上一篇概述了敏捷开发的一些基本原则，这一篇 针对其中较重要的 计划、测试 和 重构 分别做介绍。

前言

　　本系列内容为 Robert C. Martin 敏捷开发一书的读书笔记，上一篇概述了敏捷开发的一些基本原则，这一篇 针对其中较重要的 计划、测试 和 重构 分别做介绍。

一、 计划

　　1. 初始探索

　　　　项目开始阶段，开发人员和客户要尽量确定出那些真正重要的用户素材，不要试图去找出所有的用户素材。

　　　　开发人员共同对这些素材进行估算。用“点数”来表示实现素材所需要的相对时间。

　　　　过大或过小的素材都是难以估算的。

　　　　随着项目的进展，由于可以度量每次迭代中已经完成的用户素材点数，所以对于速度的度量会越来越准确。

　　2. 发布计划

　　　　如果知道了开发速度，客户就能够对每个素材的成本有所了解。

　　　　对于首次发布，客户挑选本次发布中他们想要实现的素材，并大致确定这些素材的实现顺序。

　　　　由于开发速度开始时并不准确，所以选择也是粗略的。当开发速度准确一点时，可以再对发布计划进行调整。 

　　3. 迭代计划

　　　　开发人员和客户决定迭代规模，一般需两周。

　　　　迭代期间用户素材的实现顺序由技术人员来决定。一旦迭代开始，客户就不能更新该迭代期内的素材。

　　　　即使没有完成所有的素材，迭代也要在指定的日期结束。然后估算目前完成的素材，计算出本次迭代的开发速度。

　　4. 任务计划

　　　　开发人员在客户的帮助下把素材分解成开发任务，一个任务就是一个开发人员能够在4-16小时内实现的一些功能。

　　　　开发人员可以签订任意类型的任务。

　　　　每个开发人员都知道在最近一次的迭代中所完成的任务点数，这个数字可作为下一次迭代中的个人预算。

　　　　在迭代进行到大概一半的时候，团队会召开一次会议。检查和调整开发任务。

　　5. 迭代

　　　　每次迭代结束时，会给客户演示当前可运行的程序。客户会以新的素材的方式提供反馈。

　　6. 结论

　　　　通过一次次的迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。

　　　　开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理的计划。

　　　　管理人员从每次迭代中获取数据，并且使用这些数据来控制和管理项目。

二、 测试

　　编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。

　　1. 测试驱动的开发方法

　　　　建议在设计程序前先设计测试方案，好处如下：

　　　　a. 程序中的每一项功能都有测试来验证它的操作的正确性，这个测试套件还可以给以后的开发提供支援。

　　　　b. 首先编写测试可以迫使我们从程序调用者的有利视角去观察我们将要编写的程序。有利于设计出便于调用的软件。

　　　　c. 易于调用和可测试的程序，一定是低耦合的程序。

　　　　d. 测试程序是一份可编译可运行的文档，它保持最新，而且不会撒谎。

　　2. 验收测试

　　　　单元测试是用来验证系统中个别机制的白盒测试，而验收测试是用来验证系统满足客户需求的黑盒测试。

　　　　验收测试由不了解系统内部机制的人编写。一般用脚本语言来编写。

　　　　首先编写验收测试，可以使系统具有可测试性，需要在很高的系统架构层面对系统进行解耦合。

三、 重构

　　每一个软件模块都应该具有三项职责：

　　a. 完成它应该完成的功能。

　　b. 要尽可能简单的应对变化。

　　c. 要和阅读它的人进行沟通。

　　在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构的过程--称之为 重构。

后记

　　计划 属于过程管理范畴，需要在实践中去摸索适合自己的方式。

　　灵活运用 测试 和 重构 中介绍的方法，有利于我们生产出包含 整洁代码 和 良好架构 的项目。