CSD学习之旅

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、何时重构

增加新功能

    .重构心有代码直至你能理解

    .重构设计让新功能很容易加进去

修复缺陷

   .重构以理解代码

代码评审的直接效果

    .允许更高层的建议

    .不要给重构分配时间，融合的日常的活动里面