TDD - Test Drive Development training
可读性/代码重构：
尽量不要依赖注释（应该解释why而不是how）来提高代码的可读性、可维护性，而是通过抽取方法（private）（因为注释很多时候会变得与实际内容不符，而抽取方法后会变得很容易理解以及定位，修改）
变量的定义和使用要放的近一些，提高可读性
有时候使用同一个变量和常量导致的循环会导致耦合，为了解耦，可以把变量用其计算方法代替，这个抽取的反操作叫做in line
程序员给方法，变量，常量起名字很难，应该让业务来定义，或者三方一起定义一个词汇表
首先考虑代码的可维护性，其次才是性能优化。（因为编译机器会帮你一部分优化）
分解方法，归入到对应的类，分解类，函数式编程
单元测试
敏捷不是没有文档，而是说文档是在代码中，并且可运行（单元测试）
测试代码和实现代码应该是相互校验的，测试代码越简单越好：given, when, then。
如果没有单元测试，开发人员需要通过大量测试保证重构之后系统的行为没有发生改变–这也是重构的主要障碍之一
TDD - test driven development：
测试用例谁写呢?
验收测试驱动开发：三方（测试开发和产品）一起确定测试场景，然后开发去实现单元测试代码。提倡测试尽早参与开发，预防开发缺陷。
TDD为何难以落地？
简单的程序可能一次把所有的测试场景写完，然后开发全场景。
但是复杂的程序可能需要N个TDD循环，一步一步地探索，实现，测试，通过。 （这种方法在简单程序上会显得比较傻）
开发对TDD的接受程度如何?
接受度分人群：中级比较容易接受。初级开发没有经历过维护代码的痛苦，没有质量意识；高级开发不需要假设自己容易犯错，除非是为了方便别人维护。
重构关注那些要做需求变更或者bug修复的代码部分，对于运行良好的代码和从来不用的代码先不更改.
SBE
Specification by Example (SBE) 是敏捷社区中一种主流的需求呈现和梳理的方式。每一条
需求都是一个真实的测试用例，有详细的上下文和具体的测试数据，从而以非常直观、无歧义的方式传递需求。它的好处在于：
- 业务方在提出需求时，更深入地思考需求背后的业务痛点/诉求是什么，确保需求具有高业务价值；
- 产品方管理产品需求时，围绕业务场景来组织、梳理；
- SBE需求的文档工作量较少，鼓励产品经理与团队面对面地高效沟通，从而大幅提高工作效率，减少沟通失误；
- 研发团队更容易理解以SBE方式呈现的需求，实例化展现，所有人对于需求的理解都是一致的，不会出现因为需求细节沟通不足而导致的、开发过程中的反复。
- 测试团队SBE需求同时也可以被直接用做自动化测试用例，有效地提高了代码的可测试性，减少测试成本，让自动化测试的落地变得非常容易。
-SBE是敏捷社区中越来越被关注和广泛应用的一种实践。
以团队的项目预算管理系统产品为例，在已经有大量功能上线运行的基础上，尝试使用SBE的方式组织其下一个版本的需求。在为时三小时的培训过程中，参与者从业务方、产品负责人、研发团队、测试人员等多个角度体验SBE给团队带来的变化和好处。
