敏捷开发

1、敏捷开发

一、概念，能够参考敏捷宣言，强调适应变化，四句指导

个体和互动 高于 流程和工具（动员每一个人积极交流，相互之间能够 battle，头脑风暴）；

工做的软件 高于 详尽的文档（好的代码是不须要注释和文档的，顶多有一些规范指南一类的在线协做文档）；

客户合做 高于 合同谈判（真心实意为客户创造价值，而不止于眼前的功能交付，这个很难，由此还专门有一个角色去 control 这件事）；

响应变化 高于 遵循计划（计划是赶不上变化的，随时改需求随时变更迭代计划，有迭代的概念）；

基于于右边，而更注重左边的价值，并非说彻底抛弃传统的瀑布式开发。

二、人员架构

由于公司没有所谓的各类领导，这里就说下交付组里，我所见的一些角色，也是天天在一块儿工做的小伙伴：

PM：项目管理者，这里不是项目经理，负责和客户签合同，各类会议的组织者，没有项目经理那种权利 BA：业务分析师，专门和客户谈需求，超强的交流和控制客户的能力，几乎天天都和客户泡在一块儿开会过需求，疯狂开会，驱动客户（咱们组的BA是御姐型的，气场极强） QA：测试人员 DEV：开发人员，其中有掌握技术话语权的 TL

PO：比较特殊，是客户某的部门领导人，通常和 PM 单独沟通，几乎没出现过，网友同样的存在

一个团队通常 1 PM、1 BA、1 QA 、6 DEV (三前三后，至少两个TL)

三、会议

IPM：迭代会议，每一个迭代开始以前开一次，主要是排下个迭代的故事卡（任务卡），并给每张卡估点，我遇到的是两周一个迭代（通常会有卡墙，有物理的，也有线上的）

Showcase：开发成果展现，每一个迭代结束开一次，通常是BA或QA给客户演示上个迭代作的功能，固然也是优化和新改动提得最多的时候

Retro：回顾会议，每一个迭代结束开一次，讨论上个迭代团队作得好和作得很差的事（不是针对和人，不含人身攻击），并给出改进方案，在下个迭代中执行

Stand Up：天天早上的站会，你们站成一圈，通常由 PM 主持，轮流阐述本身的昨天工做内容和工做进度，和今天要完成的工做，以及遇到的一些问题，及时反馈出来（咱们组有个小龙猫的毛绒玩具，你们挨个传递，挨个阐述）

天天还有 Code Review，动态安排时间，咱们团队一直坚持，刚开始是先后端一块儿过昨天每一个人写的代码，后面时间太长，就先后端分开。你们一块儿来找茬，你的命名和代码逻辑划分，代码风格，都有个能会被挑刺。在相互找茬的过程当中，坚持下去，对我的的成长有很大很大的帮助。

四、写代码

DEV 要作开发，就要先领故事卡，俗称开卡，本身选好一张故事卡，拉上BA和QA去过其中的细节，理清细节，而后才能上手开发，开发完后再拉上BA和QA去结卡，检查卡中的功能是否是都完成了，有问题就被打回去改，直到BA和QA以为完善了，才能关卡。。。

代码质量要求很严格，遵循 TDD，前端有lint，有单元测试（不能偷懒，并且有覆盖率要求），有 e2e 测试（必须写，和QA一块儿看），当你的代码走过这三个流程，提交到公共仓库，CI 自动构建会拉你的代码，再走一遍测试（挂了就要修代码），而后自动发布新版本到 Dev 环境。

你觉得这就完了？还有代码嗅探器，时刻在扫描代码仓库，有两个重复的函数不行、重复率过高不行、使用了骚代码去作类型转换之类的不行、空间内有命名重叠不行。。。。这一套下来，再加上 codereview，菜鸟开发天天一半的时间都在改昨天的代码。

项目还有规定，CI 不能红过夜，当天的问题当天要修好。。。。

2、TDD（测试驱动开发）

1.TDD是什么

TDD 是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码以前，先编写单元测试用例代码，测试代码，肯定须要编写什么产品代码。保证软件开发中的质量

2.TDD 有三层含义：

Test-Driven Development，测试驱动开发。

Task-Driven Development，任务驱动开发，要对问题进行分析并进行任务分解。

Test-Driven Design，测试保护下的设计改善。TDD 并不能直接提升设计能力，它只是给你更多机会和保障去改善设计。

3.为何TDD

简单设计

提早澄清需求：先写测试能够帮助咱们去思考需求，并提早澄清需求细节，而不是代码写到一半才发现不明确的需求。

快速反馈：快速反馈是单元测试的好处。debug free

安全网：TDD 的好处是覆盖彻底的单元测试，对产品代码提供了一个保护网，让咱们能够轻松地迎接需求

TDD流程

1.先分解任务，分离关注点,把一个大需求拆成多个小需求, 也能够拆出多个函数来

2.列 Example，用实例化需求，澄清需求细节

3.写测试，只关注需求，程序的输入输出，不关心中间过程

另外：好的单元测试应该符合几条原则：

简单，只测试一个需求

符合 Given-When-Then 格式

速度快

包含断言

能够重复执行 先写测试再写需求

4.写实现，不考虑别的需求，用最简单的方式知足当前这个小需求便可 重构，用手法消除代码里的坏味道

5.写完，手动测试一下，基本没什么问题，有问题补个用例，修复 转测试，小问题，补用例，修复（测试经过后可进行重构，优化代码）

6.代码整洁且用例齐全，信心满满地提交

TDD 的三条规则

1.除非是为了使一个失败的单元测试经过，不然不容许编写任何产品代码

2.在一个单元测试中，只容许编写恰好可以致使失败的内容（编译错误也算失败）

3.只容许编写恰好可以使一个失败的 unit test 经过的产品代码

若是违反了会怎么样呢？

1.违反第一条，先编写了产品代码，那这段代码是为了实现什么需求呢？怎么确保它真的实现了呢？

2.违反第二条，写了多个失败的测试，若是测试长时间不能经过，会增长开发者的压力，另外，测试可能会被重构，这时会增长测试的修改为本。

3.违反第三条，产品代码实现了超出当前测试的功能，那么这部分代码就没有测试的保护，不知道是否正确，须要手工测试。可能这是不存在的需求，那就凭空增长了代码的复杂性。若是是存在的需求，那后面的测试写出来就会直接经过，破坏了 TDD 的节奏感。

本质是： 分离关注点，一次只戴一顶帽子

在咱们编程的过程当中，有几个关注点：需求，实现，设计。

TDD 给了咱们明确的三个步骤，每一个步骤关注一个方面。

红：写一个失败的测试，它是对一个小需求的描述，只须要关心输入输出，这个时候根本不用关心如何实现。

绿：专一在用最快的方式实现当前这个小需求，不用关心其余需求，也不要管代码的质量多么惨不忍睹。

重构：既不用思考需求，也没有实现的压力，只须要找出代码中的坏味道，并用一个手法消除它，让代码变成整洁的代码。

注意力控制： 使用 TDD 开发，咱们要主动去控制注意力，写测试的时候，发现一个类没有定义，IDE 提示编译错误，这时候你若是去建立这个类，你的注意力就不在需求上了，已经切换到了实现上，咱们应该专一地写完这个测试，思考它是否表达了需求，肯定无误后再开始去消除编译错误。

实战操做技巧

1.选一个最简单的用例，直接开写，用最简单的代码经过测试。逐渐增长测试，让代码变复杂，用重构来驱动出设计。

2.维护时也遵循 TDD 流程，先修改测试代码成需求变动后的样子，让测试失败，再修改产品代码使其经过。这样你就不是在维护测试用例，而是在利用测试用例。

好比word-frequency-tdd-demo的例子，计算文件中单词的频率

①首先想一下大概的流程，要作什么

（主要是为了任务拆分）

②列输入输出的example

大概能够想到以下的用例：

"" => ""  为空的状况
"he" => "he 1"，一个单词，驱动出格式化字符串的代码
"he is" => "he 1\r\nis 1"，两个不一样单词，驱动出分割单词的代码
"he he is" => "he 2\r\nis 1"，有相同单词，驱动出分组代码
"he is is" => "is 2\r\nhe 1"，驱动出分组后的排序代码
"he is" => "he 1\r\nis 1"，多个空格，完善分割单词的代码
复制代码