这是冲锋陷阵的一周。由于任务沉重，我牺牲了自己的所有学习时间。而且就目前的形势看，恐怕接下来至少到暑假结束也没什么业余时间。
这周主要完成了两个任务。先是将程序从单GPU扩展到多GPU；再是对程序中现有 的算法 进行了扩展，实现了老板提出的部分扫描 策略。
由于最近首次尝试给自己做的软件加入单元测试，而且还开始尝试测试驱动的开发模式 （TDD） ，因此单GPU改多GPU的工作一开始进展甚是缓慢，上周花了不少时间来捣腾CppUnit，并且一直在思考应该怎样对代码进行重构，以增强其可测性（Testability）。本来预计要到这个月结束的时候才能 做好 多GPU的程序。谁知上周末老板就提出了要尽快实现部分扫描策略，以分析手头的大数据。于是只好牺牲不少严谨性，还没来得及为最核心 的函数 写单元测试就开始实现产品功能，赶紧先把多GPU的程序给做好，再实现老板提出的部分扫描策略。
当然我还是在保证进度的前提下尽可能地写了测试， 花了将近两天的时间先给 部分扫描策略所用到的一些接口写了 测试用例 ，最后用半天多的时间实现该功能。在这个过程中，我预先写好的测试用例还真的检测到了后写的产品代码中的错误——虽然那是非关键的代码区。 不过搞笑的是，当我刚把产品代码写好时，单元测试仍然有一堆的失败，后来发现原来是我的很多测试代码写错了 -_-。
初尝单元测试和TDD，感受不少。
对于单元测试，最大的感受就是采用它后，我对自己写的代码更有信心了。以前没有测试的时候，随着代码体积不断增大，我的信心会逐渐降低，每次运行自己写的应有都会有点提心吊胆，担心它会在什么地方出错。而现在看着CppUnit在Visual Studio的输出窗口中打出的OK字样，我心里面就会有不少底气。而且测试用例设计得越全面，这种底气就越足。另外，单元测试有助于开发者提前发现产品代码中的错误，并缩小错误的排查范围——其实这才是单元测试的主要目的。
对于TDD，最大的感受就是这玩意儿虽然是个好东西，但它对开发者的要求还真是比较高。除了要求开发者能设计好的测试用例，它还要求开发者能顶住工期压力 ，不要因为急于 写产品代码而对测试草草了事——也就是说这玩意儿要求开发者要有很好的心理素质……记得周三写了一白天的测试用例之后，我惴惴不安地说：“再这么下去我就不叫Dev Intern了。”旁边的SDET鼓励道：“我们的Dev也要写很多Unit Test，再说TDD不是还有个D么。:)”于是晚上我还是沉住了气，老老实实地继续写测试。
当然这里有个度的问题。测试写到什么程度为止，是需要把握的。测试输入的组合爆炸是个现实的问题，迄今仍有不少计算机科学的研究者在为此探索。而且有时候也无法严格地执行TDD，还是要开发先行，有条件的话测试再跟上——如果不这么做的话，我的多GPU程序就别指望这星期能诞生了。我想这样做是对的，毕竟软件工程并不是一门严谨的科学，而是一门实践的技艺。事实上，我的单元测试 也并不是严格的单元测试。当函数A调用函数B的时候，严格的单元测试应该是用一个Mock替换函数B，再测试函数A。但由于时间太有限，我无法（也不知道该怎么）为函数B做Mock，因此我所能做的只是 对函数B进行测试，尽量保证其正确性，然后在这种情况下测试函数A——实际上这已经是集成测试了。另外，由于没有时间对关键类进行更大规模的重构，我只能将对应的测试类声明为友元，对关键类的私有函数进行测试——虽然这么做是不提倡的。在保证进度的前提下，尽可能学习更先进的技术，并将其应用到项目中，以使后续项目做得更好——我想这是实际做项目时所应坚持的原则。
最后，TDD让我更多地从上层开始思考应该怎样实现或改动一个产品——虽然不用TDD我也会这么做，但是TDD确实会对设计有所影响。以前我写代码时从不会考虑一个函数、一个类是不是方便测试，而这两周的工作让我对这方面尤其注意。 而且现在我还形成了一种新的开发习惯：先写头文件（用C++时），定义接口，在这个过程中头脑里会逐渐形成一个产品框架的雏形；然后开始写测试用例；最后写产品代码。不过我觉得除了可测性以外，TDD对于改善代码框架的设计并没有太大的帮助。好的设计思想还是得益于大量的开发经验。
路漫漫其修远兮，前方肯定还有不少产品代码要写，希望测试的加入能让我的功力增长不少。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。