我对这句话的理解是：

　　1）任何一次提交新的代码都需要添加针对这些新功能的测试用例

　　2）无论设计函数还是类，对外暴露的接口都应该做到明确，清晰，不会给人模棱两可的感觉，提供的功能点尽可能的单一，doonething，doitwell。

　　简而言之，我所理解的“测试驱动开发”，十分强调对接口的设计，以及针对这个接口所需要考虑的异常和测试用例。接口是对外的保证，而测试用例是验收者，每次的修改，都需要保证之前和现在的用例能顺利通过。

　　所以，对开发人员来说，如果有这个“测试驱动开发”的观念，那么在设计编写代码的时候会很容易的形成几个好习惯，比如他会反问自己以下几个问题：

　　1）新增的代码提供的是什么功能？功能点是否足够的单一，明确，比如本次测试的代码仅针对功能A，下一次的仅针对功能B，假如B功能还依赖于A功能，那么首先要保证A功能点正确提交。切忌万不得已的情况下不可以将多个功能点放在一次提交中，这样，以后回溯问题时会加大难度，也会给codereview等带来困难。

　　2）新增的功能，对外暴露的接口是哪些？有没有冗余，不明确的接口设计？这些接口是不是刚刚好不多不少足够了？

　　3）对新增的功能，明确了对外应该提供什么接口之后，还需要反问自己：可能在哪些情况下出错，每种出错的情况应该如何处理，如何通知调用者，代码的注释是不是对一些情况作了说明。

　　4）最后，对新增的功能，考虑了哪些测试用例，测试是否充分，是否考虑了很多异常的情况？

　　所以，每次的代码提交都是一件很严肃的事情，这意味着，你对系统现有的代码做出了一些修改，可能是接口的修改，可能是实现的修改。如何能保证你的修改没有问题，codereview是一点，好的codereview是一件很耗时的事情，这需要reviewer负责任，同时最好还要多少对这部分代码有了解。如果reviewer能力较强，又比较负责，那么一次review相当于是一个老师在阅读作业，他会给出你一些建议；反之，如果你作为reviewer去review一个高水平的人的代码，又可以从阅读中学习对方的思路。总而言之，我觉得做好codereview是一件能够迅速提高“经验值”的捷径，早前我阅读过许多开源项目，学习了很多别人的技巧思路，codereview比之更近了一步--因为我还有机会与作者面对面的一起交流。另外，除了codereview之外，每次提交都有测试用例，也是保证代码质量的方式之一，如果把代码比做一个球场，那么测试用例就是站在这个球场门口进行安检工作的保安，不论做了什么修改，只要保证测试用例写的好，那么基本上都跑不过这个保安的掌心。有了测试用例，项目的修改才有了保证，它所提供的功能，都是可控的，有保证的。

　　另外，每次提交的修改功能点尽量的单一也是很重要的一点，因为假设你想做的事情很多，比如做了A又想做B，发现做B功能需要实现C功能，实现C功能首先要做D功能。。。。子子孙孙，无穷尽也。这样会导致你的代码提交codereview时被通过的时间慢（原因有很多，比如你需要提交测试用例多了，比如别人的codereview时间多了）。还有一点，假如别人赶在你之前提交了代码，而你的修改需要依赖别人的代码，这样导致了你需要合并别人的改动，这又是一件很麻烦的事情。

　　所以，当接手一个任务时，如何按照层次顺序划分任务，每次提交都保证尽可能提交少的功能点，而且又能保证每次的提交都有严格的测试用例，也是对开发人员的一个考验。当然，这些也许在动手的时候不能百分百的考虑清楚，但是如果完全的没有考虑过，上手就做，迟早都要还的。

　　另外，有了同新增代码一起提交测试用例的要求之后，“看上去”每次提交的速度慢了，因为还需要撰写测试用例，所以对任务时间点的估计可能也需要改变，我个人的估计是写代码时间：测试时间（包括写测试用例+改bug）：根据codereview修改代码的三者之间比例大概为4:3:3，所以如果一个任务给我五个工作日的时间完成，也许以前我到了第四天才编码完成，而现在就要尽量做到第三天之内能完成编码了。不过这个比例并不确定，依个人的素质而定，有的人写代码质量很高，自己已经把很多情况在写的时候考虑进去了，所以后期测试和codereview时出现问题的机会少，反之，有的人的代码质量较差的，可能经常在codereview的时候被打回去重构（甚至于重写）的，后面的比例就要增加了。以我而言，如果能在保证代码质量的同时，减少后面两项的时间比例，那应该是说明了我的代码质量有了提高了。

　　总而言之，接口的设计，任务层次顺序的划分，都是很考验人经验的活，语言的表达总是苍白的，需要实实在在的去实践体会。本人拙见，欢迎探讨。（以上言论仅代表作者的个人观点，不代表51Testing观点）