20155314 2016-2017-2 《Java程序设计》实验三敏捷开发与XP实践

实验内容

XP基础
XP核心实践
相关工具

实验知识点总结

（一）敏捷开发与XP

软件工程：把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程
软件工程包括以下领域：
- 软件需求分析
- 软件设计
- 软件构建
- 软件测试
- 软件维护
软件开发流程：人们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想体系。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”
软件开发流程的目的：为了提高软件开发、运营、维护的效率，并提高软件的质量、用户满意度、可靠性和软件的可维护性
常见公式：
- 软件工程=开发流程+工具
- 软件=程序+软件工程和软件企业=软件+商业模式(邹欣老师给出)
常见开发流程：
- RUP(Rational Unified Process)
- PSP(Personal Software Process )
- TSP(Team Software Process )
- Agile Process
- ……
敏捷开发（Agile Development）：是一种以人为核心、迭代、循序渐进的开发方法
极限编程(eXtreme Programming，XP)：是一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流：
- XP是以开发符合客户需要的软件为目标而产生的一种方法论
- XP是一种以实践为基础的软件工程过程和思想
- XP认为代码质量的重要程度超出人们一般所认为的程度
- XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件
XP软件开发是什么样的通过XP准则来表达：
- 沟通：XP认为项目成员之间的沟通是项目成功的关键，并把沟通看作项目中间协调与合作的主要推动因素。
- 简单：XP假定未来不能可靠地预测，在现在考虑它从经济上是不明智的，所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。
- 反馈：XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。
- 勇气：代表了XP认为人是软件开发中最重要的一个方面的观点。在一个软件产品的开发中人的参与贯穿其整个生命周期，是人的勇气来排除困境，让团队把局部的最优抛之脑后，达到更重大的目标。表明了XP对“人让项目取得成功”的基本信任态度。
一项实践在XP环境中成功使用的依据通过XP的法则呈现，包括：
- 快速反馈
- 假设简单性
- 递增更改
- 提倡更改
- 优质工作
XP软件开发的基石是XP的活动，包括：
- 编码
- 测试
- 倾听
- 设计

（二）编码标准

编写代码一个重要的认识是“程序大多时候是给人看的”，编程标准使代码更容易阅读和理解，甚至可以保证其中的错误更少。
编程标准包含：
- 具有说明性的名字
- 清晰的表达式
- 直截了当的控制流
- 可读的代码和注释
- 在追求这些内容时一致地使用某些规则和惯用法的重要性
编码标准中的版式就是一个很好的例子，版式虽然不会影响程序的功能，但会影响可读性。程序的版式追求清晰、美观，是程序风格的重要因素。
Java中的一般的命名规则：
- 要体现各自的含义
- 包、类、变量用名词
- 方法名用动宾
- 包名全部小写，如：io，awt
- 类名第一个字母要大写，如：HelloWorldApp
- 变量名第一个字母要小写，如：userName
- 方法名第一个字母要小写：setName
- ...

（三）结对编程

结对编程是XP中的重要实践。在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。

结对编程中有两个角色：
- 驾驶员（Driver）是控制键盘输入的人。
- 领航员（Navigator）起到领航、提醒的作用。
如何结对编程：
- 驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
- 领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。
- 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。没有“我的代码”、“你的代码”或“他/她的代码”，只有“我们的代码”。
- 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
结对编程中出现分歧，应对事不对人

（四）版本控制（Version Control）

代码仓库
版本控制的好处：
- 版本控制提供项目级的 undo（撤销）功能：没有什么事情是终结版本，任何错误必须很容易回滚。假设你在使用世界上最复杂的文字处理系统。它具备了所有的能想到的功能，就是没有支持 DELETE（删除）键。想象你打字的时候得多么的谨慎和缓慢吧，特别是一篇超大的文档的快临近末尾的时候，一个不小心就要重头再来（试想你选中所有的文字，不小心按了 DELETE 键，因为没有撤销功能，只好重新录入）。编辑文字和版本控制相同，任何时候都需要回滚，无论是一个小时，一天，还是一周，这让你的团队工作自由快速的工作，而且对于修正错误也非常自信。
- 版本控制允许多人在同一代码上工作，只要遵守一定的控制原则就行。再也不会发生诸如一个人覆盖了另一个人编辑的代码，导致那个人的修改无效这样的情况。
- 版本控制系统保存了过去所作的修改的历史记录。如果你遭遇到一些惊讶的代码，通过版本控制系统可以很容易找出是谁干的，修改了什么，修改的时间，如果幸运的话，还能找出原因。
- 版本控制系统还支持在主线上开发的同时发布多个软件版本。在软件发布的时候也不需要整个团队的停止工作，不需要冻结代码。
- 版本控制也是项目级的时间机器，你可以选择任何一个时间，精确地查看项目在当时的情况。这对研究非常有用，也是重现以前某个有问题的发布版本的基础。

（五）重构

重构的概念：

重构(Refactor)，就是在不改变软件外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更。

重构中一个非常关键的前提就是“不改变软件外部行为”，它保证了我们在重构原有系统的同时，不会为原系统带来新的BUG，以确保重构的安全。
- 如何保证不改变软件外部行为：重构后的代码要能通过单元测试。
- 如何使其更加易于阅读、易于维护和易于变更：设计模式给出了重构的目标。
修改软件的四种动机：
- 增加新功能
- 原有功能有BUG
- 改善原有程序的结构
- 优化原有系统的性能
需要重构的地方：有臭味道（Bad Smell）的代码——Duplicated Code(重复的代码)
- 最单纯的Duplicated Code就是［同一个class内的两个方法含有相同表达式(expression)］。这时候你需要做的就是采用Extract Method提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。
- 另一种常见情况就是[两个互为兄弟(sibling)的subclasses内含有相同表达式]。要避免这种情况，只需要对两个classes都使用Extract Method，然后再对被提炼出的代码使用Pull Up Method，将它推入superclass内。
- 如果代码之间只是类似，并非完全相同，那么就得运用Extract Method将相似部分和差异部分割开，构成单独一个方法。然后你可能发现或许可以运用Form Template Method获得一个Template Method设计模式。
- 如果有些方法以不同的算法做相同的事，你可以择定其中较清晰的一个，并使用Substitute Algorithm将其它方法的算法替换掉。
- 如果两个毫不相关的classes内出现Duplicaded Code，你应该考虑对其中一个使用Extract Class，将重复代码提炼到一个独立class中，然后在另一个class内使用这个新class。但是，重复代码所在的方法也可能的确只应该属于某个class，另一个class只能调用它，抑或这个方法可能属于第三个class，而另两个classes应该引用这第三个class。你必须决定这个方法放在哪儿最合适，并确保它被安置后就不会再在其它任何地方出现。
一个完整的重构流程：
1. 从版本控制系统代码库中Check out code
2. 读懂代码（包括测试代码）
3. 发现bad smell
4. Refactoring
5. 运行所有的Unit Tests
6. 往代码库中Check in code
在IDEA下重构实践如下图：