开发之前的产品思维：

• 为什么要做这个特性，它会给用户带来怎样的价值？
• 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
• 达成这个目的是否有其它手段？是不是一定要开发一个系统？
• 这个特性上线之后，怎么衡量它的有效性？

四项原则

• 以终为始；
• 任务分解；
• 沟通反馈；
• 自动化。

任务分解

11.学习任务分解
定义：正是通过将宏大目标进行任务分解，马斯克才能将一个看似不着边际的目标向前推进。

软件开发的任务分解：分治算法

总结：那么请记住：动手做一个工作之前，请先对它进行任务分解。

—————————-
12、测试也是程序员的事情
如何保证质量：在开发阶段把代码和测试都写好。

自动化测试：Junit

将测试分成关注最小程序模块的单元测试、将多个模块组合在一起的集成测试，将整个系统组合在一起的系统测试。

不是用单元测试框架写的测试就是单元测试。
总结：那请记住：多写单元测试。

13、先写测试用例？
TDD(测试驱动开发)：红(未通过)-绿(通过)-重构

因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解。

测试驱动设计：Mock框架(分层测试)
一个好的解决方案是尽量不写 static 方法。能不用尽量不用

写代码之前，请先想想怎么测。

总结：那请记住：我们应该编写可测的代码。

14、大师级程序员的工作秘笈
——————————-
Kent Beck：每当遇到一件要做的事，Kent Beck 总会先把它分解成几个小任务，记在一个清单上，然后，才是动手写测试、写代码、重构这样一个小循环。等一个循环完成了，他会划掉已经做完的任务，开始下一个。(有问题就记录下来，保证问题不丢失。然后去解决这些问题)
可以保证每次代码都可以提交

坚持微操作(每次操作子任务)
充分利用git的分支功能

总结：那请记住：将任务拆小，越小越好。

15、手把手分解任务
这个要看文档，太多了

总结：那请记住：按照完整实现一个需求的顺序去安排分解出来的任务。

16、怎么写好测试
为什么测试测不好？只有将复杂的测试拆分成简单的测试，测试才有可能做好。
测试结构：前置准备，执行，断言和清理

测试一定要有断言
你真正应该做的是，多写几个测试，每个测试覆盖一种场景。

总结：要想写好测试，就要写简单的测试。测试标准A-TRIP

17、砍需求(不懂)
有用户故事：
需求分解的一个原则是，粒度越小越好。分成用户故事
然后进行讨论

总结：想要管理好需求，先把需求拆小。

18、