bjdp.org第14次编程道场回顾
* 时间:2014.03.30, 2:00-6:30pm
* 地点:北京优纳科技有限公司
* 参加人数:21人
* 活动主题:用TDD方法和Visual C++ 2012实现带有特性开关的FizzBuzz(FizzBuzzWithFeatureToggle)
* 伍斌完成该题目的源代码:请点击本微信左下角“阅读原文”链接
* FizzBuzzWithFeatureToggle题目描述:
您是一个程序员,假如要实现一个FizzBuzz的游戏。FizzBuzz是国外小学里老师和孩子们一起玩的游戏。下课前5分钟,老师让孩子们站成一个圈,然后用手指指着第一个孩子,第一个孩子要迅速地说“1”;接着老师快速地指第二个孩子,第二个孩子要迅速说“2”;依次类推,每个被老师指到的孩子要迅速地递增报数。而且,如果孩子遇到3的倍数,就不能说数字,而要说“Fizz”;如果遇到5的倍数,则要说“Buzz”;如果既是3又是5的倍数,则要说“FizzBuzz”。说错或反应慢的孩子就不能再继续游戏。看谁能坚持一直游戏到最后。这是一个很锻炼乘法心算和反应能力的游戏。
您作为程序员,已经按照项目组里的产品需求专家累君交代的需求实现了FizzBuzz这个游戏。有一天,累君找到您,说:“咱们的CEO瞧不死在昨天跟我说,为了提升咱们这个游戏在中国市场的竞争力,考虑到中国人勤劳智慧,可以增加游戏的难度和趣味性,即当孩子遇到3的倍数时,除了说Fizz外,还要摸一下头;当说Buzz时还要摸一下肩膀;当说FizzBuzz时还要摸一下膝盖。但这些新增的功能仅仅针对中国市场。对于中国以外的市场,还是按照以前只说Fizz, Buzz和FizzBuzz来实现。”您打算用面向对象的开发方法(比如State或Strategy设计模式)来实现Business特性开关,并试图做到:无论特性开关是打开还是关闭,针对国内和国外两个市场的功能的测试都能够正常运行通过。
活动过程
1. 伍斌现场编程演示用TDD方法实现FizzBuzzWithFeatureToggle(1.5小时)
2. 各位匠友用绘图和代码做自我介绍(0.5小时)
3. 各位匠友结对编程驯服Trivia烂代码(每对7分钟,共1.5小时)
4. 回顾(0.5小时)
回顾要点
本次活动采用了从ThoughtWorks仝键老师那里学到的回顾方法,即每人在小纸条上写下:做得好的(Well)、需要改进(Less Well)的和疑问(Puzzles)。以下是要点总结,并附带疑问解答。
Well
* 活动氛围很好。
* 活动的流程控制得很流畅,也很稳定。
* 时间掌控合理;举例简单、由易到难;不懂C++也能看懂很多。
* 主持人实例演示和全体听众参与结对编程实战编程效果好,实践操练印象很深。
* 特别喜欢结对编程的部分,看到很多不同的思路。
* Coding Dojo活动能让平时交流不多的程序员能更加open。
* 分享开发过程的新模式(TDD、重构到设计模式)能够开拓思路,值得借鉴和利用。
* TDD和重构等技术很实用,对自己以后的开发有所帮助。
* 编程操练的题目很经典。
* 通过实际操练暴露了程序员平时工作中的很多不良习惯,有利于改进。
* 熟悉了C++单元测试框架googletest。
Less Well
* 现场两位听众进行结对编程时,由于没有不断大声说出想法,导致观众不明白他们的思路。
* 设计模式的讲解有点冗长。
* 自己没有勇气亲自上去体验结对编程。
* 到最后仍有程序员按自己的想法来闷头写代码,还不是TDD。
* 参与者准备不够充分。可以事先在家做一下题目。
* 可增加设计过程的分析和讲解。
* 时间可以再长一些,技术可以再深入一些。
Puzzles(含我个人的一下解答)
* TDD所追求的终极目标是什么?简化?效率?标准?
答:我认为TDD的终极目标是“增强反馈”,这体现在测试的运行成败能够增强对生产代码行为是否符合规格的反馈,测试的定义代码本身能够增强对有关生产代码行为规格的理解的反馈。另外这种反馈能够被低成本地复用,比每次用IDE做debug要高效。
* TDD和黑白盒测试的关系是什么?
答:黑盒和白盒测试都是在生产代码已经编写完成后再进行的。而TDD的测试代码是在生产代码编写前写的,能够比前者更加容易地写测试,因为没有生产代码这个婆婆管着。
* 大系统也能用TDD开发吗?测试文件会不会太多不便于管理?
答:大系统也是由各个小模块所组成,这些小模块都可以用TDD来开发。有效地编写测试以便于管理是另一个大的话题,建议读一读Gerard Meszaros的xUnit Test Patterns: Refactoring Test Code一书。
* 编程前为何未先讨论来制定一个详细的编程设计说明?
答:事先所做详细的编程设计说明,往往在编程过程中会逐渐发生变化。而程序员一般很少在改代码的同时修改设计说明,使得这些说明逐渐成为成语刻舟求剑里面的那个刻在船上的记号,而在以后失去了参考的价值。如果能够经常运行测试,那么这些测试就是流水不腐的设计说明。
* 如何提高开发水平?
答:长期、刻意、专注地与他人进行编程操练。
* 训练的系统性如何提高?
答:在训练之余要多读软件开发的经典名著,书目可参考ThoughtWorks的程序员读书雷达:http://www.oschina.net/news/39816/thoughtworks-developer-reading-radar
* 如何更好地照顾不同水平的“匠友”?
答:一方面我会努力营造一个安全、轻松、娱乐的活动气氛;另一方面,无论水平高低,希望各位匠友多参与结对编程。只要参与结对编程,都能从中获益。
* 当结对编程的两位匠友意见不一致时该如果应对?
答:日常工作生活中,合作的双方意见不一致很常见。这就需要沟通。学诚法师说:“沟通的目的不是说服对方,而是了解对方。”本着这个目的去沟通就会收到良好的效果。另外匠友姚若舟认为用“搁置、验证、让步”的方法来解决。详见在Infoq上的文章“驯服烂代码之实践、总结与讨论”:http://www.infoq.com/cn/news/2014/03/garbage-code-discuss/
* bjdp.org的编程道场活动能否坚持下去?
答:只要大家对编程操练和编程道场感兴趣,我就会坚持办下去。
* 为什么用Java和C#的人比C++的人多?
答:我想这是由市场决定的。据我统计,在bjdp.org的200多位匠友中,每10人里,会Java的有8人,会C#的有7人,会C++的有4人。
--------------------------------
喜欢我今天的文章,不妨点击右上角按钮分享到朋友圈,以广结善缘。无论是否喜欢,都可回复本条微信,我必看必回。
您看到的上面我写的文章,首发于微信公众号bjdp_org。该公众号服务于我创办的bjdp.org公益编程操练社区。在这里,程序员们聚在一起,编程、学习、找乐子;和测试工程师一起结对编写验收测试代码;与产品需求专家一块探讨如何能让软件开发的成果不离谱。程序员、测试工程师和产品需求专家,是密不可分的“三兄弟”。
欢迎在微信上搜索bjdp_org关注北京设计模式学习组。
如果您想看本公众号以往的精彩内容,请回复m