即便是放入了购物车，依然有较大流失，因此一般的购物网站都会有立刻购买的按钮。

就是从起点到终点有多个环节，每个环节都会产生用户流失，依次递减，每一步都会有一个转化率。

他的数据分析的思路是将一段时间内所有完成了三个引导页的用户都筛选出来，然后再计算他们在这之后持续回访产品的比例，同时也将这段时间里未完成三个引导页的用户筛选出来，将这些用户的留存率与完成的引导页的用户留存率做对比。

用户留存分析的第一步是按照不同的（时间/渠道/行为等）维度进行用户分组。

最核心分析的方法是根据用户行为进行分组的比较

模块化

也就是说，我的每一次重构，每一次拆分，目的都是为提高“可测试性”（我把它们都标红了）

我为每个字段定义了一种转化器（而在实际开发过程中，我们可能也会为“每种类型”定义一个）。

于是我提取出一个Tokenizer抽象，以及一个默认的逻辑实现

拆分字符串的逻辑比较复杂，因此我将其提取到一个独立的Tokenize方法中去。

依赖倒转原则（Dependency Inversion Principle）

里氏替换原则（Liskov Substitution Principle）

单一职责原则（Single Resposibility Principle）

与传统TDD的开发方式不同，我的TTD方式还是先写代码，后写测试。只不过，我会时刻关注自己的代码是否容易测试，并不断重构产品代码和测试代码。基本上它的步骤是： 写产品代码 为产品代码写测试 发现测试不容易写，于是重构产品代码 重构测试 ……

我难以接受正统TDD方式的原因，在于我总是过于习惯在拿到一个需求的时候，在脑海里率先出现设计。

TDD比Waterfall更能准确地了解需求。

TDD比Waterfall更能准确地了解需求。

所以，你怎么能保证你一开始的Test Case是适合于你后面的代码的？

管理和维护这些Mock和Stub也成了一种负担

另外，如果写得太Low Level，根据Agile的迭代开发来说，你的需求是易变的，很多时候，我们的需求都是开发人员自己做的Assumption。所以，你把Test Case 写得越细，将来，一旦需求或Assumption发生变化，你的维护成本也是成级数增加的。

如果写的太过Low Level，那么，带来的问题是，你需要花两倍的时间来维护你的代码，一份给test case，一份给实现的功能代码。

如果写的太过High Level，那么，当你的Test Case 失败的时候，你不知道哪里出问题了，你得要花很多精力去debug代码。而我们希望的是其能够告诉我是哪个模块出的问题。只有High Level的Test Case，岂不就是Waterfall中的Test环节?

You will write cleaner, less complicated code.

TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities.

TDD is detailed specification

Example of TDD

The main goal of envisioning is to identify the scope of the system and architecture of the system.

The unit test focuses on every small functionality of the system.

Acceptance test focuses on the overall behavior of the system.

In TDD, you achieve 100% coverage test.

the development team has to develop and refactors the code.

Test-Driven Development starts with designing and developing tests for every small functionality of an application.

45岁以下的年轻观众电视消费时长逐年下降，这类观众在远离传统电视，而新媒体在这类观众群中不断扩大着自己的影响力。

总体电视市场的收视量减少主要缘于近年来观众规模的逐年下降。

电视观众的流失已呈现不可逆转的趋势

电视人口：人均每日收视时长降至156分钟