什么是驱动式的前端完美开发工作流？

## 项目纵向拆分

> 哎，TDD写UI真是很无聊。

但是，结合 Storybook，我算是找到了比较完美的 UI+State 测试工作流，并且引入了 Storyshot，自动在UI完毕之后take Snapshot，然后就又发现了 image snapshot：

1. 先做组件设计， ref: http://reactjs.org/docs/thinking-in-react.html
2. 再撸 business logic 代码，纯函数 reducer 里面爽歪歪；action里面异步测试。
3. 再撸组件及其state，专注组件 JS logic 和 HTML 结构；
-------------TDD结束；Storybook CDD 开始----------------
4. 先引入组件作为 Stories（纯HTML）
5. 再撸Styling，抽取StyledComponent
6. CSS写完，自动打个快照，截图对比！

https://github.com/storybooks/storybook/tree/master/addons/storyshots#configure-storyshots-for-image-snapshots--alpha-
> 卧槽，神器啊！！！！！直接给Storybook里面每个Components截图，然后做Snapshot testing
> 然后 左边 vs 右边，中间是 diff 的不同内容！我擦擦擦，真是很完美的方案了啊喂.

> TDD business logic 就好，尽可能 pure component，然后组件样式什么的就直接CDD，在storybook里面看就好了。
反正还有 image snapshot 和 全局的 visual testing
截图比什么都来得快、来得直观
> 这个都可以删了啦，属于测细节了。测css是个错误的思路。
样式不用tdd啊～我觉得样式是个回归问题，它跟tdd关注点不一样，ui在于保证回归，而tdd在你出代码前要出结果。然而ui这事的视觉本质就导致用眼看比用代码快多了
> Design System，组件库 + theme
首先，有这样一个组件库，然后所有的字体+颜色，等等都是可统一变化的。持续演进，可以多肤色，等等。样式改起来越容易，你就会经常改，用户体验就容易越来越好。

> 之前要在一个遗留代码库上做tdd其实很坑的
好比你练了红绿循环，信心满满要施展一把时发现，现有代码库分层不清，巨多没测试的逻辑在一起，巨多直接new import进来的依赖，
> TDD 遗留代码就是个坑呀，import 直接全部 mock 掉。
spy都不想spy了，直接mock+stub想要的返回值，


### ⓵ 定义目标和原则

终极目的

Q：为什么你要花时间来做这项任务，而不是其他随便什么任务？
A：

### ⓶ 展望结果（OKRs）

利益相关人清单

Q：当你交付最终结果的时候，会如何让世界变得更好？
A：

### ⓷ 思维导图：头脑风暴/集思广益（发散）+ ⓸ 组织整理（收敛）

### ⓹ 明确「下一步行动」

能够产生反馈结果的小任务