2017年3月5-7日有幸参加了CSD的开发培训，感受颇深。感谢领导给的机会。
回想下几年前，我在做OA项目的时候，也采用了测试驱动开发（TDD），结合下这次CSD的一起做下经验总结吧。
1、TDD的学习是要先引入单元测试，先让团队熟悉下单元测试的使用。
2、说服整个团队，我们要争做有节操的程序员，保证质量，而不是制造bug。
3、单元测试其实蛮强调个人的修为，是简单完成测试任务，还是驱动开发，指导设计。
4、在推进TDD的过程中，我们实际上有结合了及时反馈的概念，做到了自动构建。每日的Junit的测试报告。
虽然没有做到很理想的“你妈喊你改bug”的语音录入情况，但也有邮件的报警。和我们每日的check in，和每天早晨的修复bug，只是为了让Junit跑的更绿一些。
测试金字塔中，单元测试我们其实当时已经做得挺好的了。
5、我们总是为了使得代码整洁，引入了诸多的设计模式，好看的代码比较免不了重构。当然本次最大的收获应该是新的开发工具会使得重构间的很多。eclipse或者myeclipse真的可以丢掉了。
6、万事开头难，但坚持更难。在项目完成，人走离散的时候。我们也渐渐不做TDD了。
我记得最开始的时候，产能很差。但当我们熟悉了这种方法，产能提升非常快。也迅速消化了bug数量。贵在坚持啊，兄弟们。
7、道场 dojo demo，实际上我们更多的是在结对的时候学到的东西。不过确实小游戏完成项目和算法。确实可以激发热情和修炼编程技能。
后续打算引入到团队里头。
8、写到最后，测试其实开发的骨子里是痛恨的，但从快乐编码的角度来讲，都差不多。当代码的坏味道被一点点消除掉的时候，那种快乐足矣会抵消对测试这种活的反抗。
9、谈谈覆盖率工具吧，我有点忘记了当时怎么做，不过麦老师推荐的开发工具确实不错。后面说点开发环境、还有编译、测试环境，想想当时破破的台式机，开个eclipse都能卡半天。这些都是影响产能和效率的原因。
我们应该在平时的交谈中去发现问题，并帮助团队提升效率和产能。
10、回头在想，我好像当时并没实际去写一个什么设计文档。文档都是为了CMMI的时候，后面补下。新人嘛，看下代码就行了。
附上：学习笔记
1、瀑布模式下开发和测试，敏捷开发下的TDD：测试应该在源头上避免bug产生，帮助开发减少bug
2、原来瀑布模式下，部署和编译时间较长，反馈周期太长了。
3、TDD的优势：
测试-Api解耦、避免过度设计、代码有重复的时候，开始重构、覆盖率较高、可重用性
4、为何要持续集成：
避免长时间紧张的整合
提供可视化程度
尽早发现问题
花更少的时间debug
有信心在可到的基础上开展工作
5、测试职能的改变：从发现缺陷到避免缺陷产生
6、团队职责
频繁迁入
不要迁入有问题的代码
不要迁入未经测试的代码
不要在构建失败后再迁入
下班前要保证掐纳入的代码能在CI服务器上通过。
7、如果没有达成共识的，放入Team agreement
8、什么是好的代码 -重构
可工作 易修改 易理解
简单，逻辑清晰，
9、何时重构
增加新功能
.重构心有代码直至你能理解
.重构设计让新功能很容易加进去
修复缺陷
.重构以理解代码
代码评审的直接效果
.允许更高层的建议
.不要给重构分配时间，融合的日常的活动里面
