现在的位置: 首页 > 综合 > 正文

北京设计模式学习组bjdp.org第6次活动(2013.07.21)回顾会纪要

2013年09月08日 ⁄ 综合 ⁄ 共 762字 ⁄ 字号 评论关闭

时间:2013.07.21,2-5pm

地点:图灵公司

参加人数:15

回顾会要点:

1)金锐分享:单元测试的Mocking技术,契约测试,何时适合用mocking(组合),何时适合用高层测试(聚合)。

2)伍斌分享:开源软件代码内在质量检查框架SonarQube:SonarQube通过什么方法来展示团队代码内在质量在一个阶段内的走势?SonarQube支持哪些编程语言?SonarQube的主要用法有哪两种(一次性、与CI集成)?用SonarQube来帮助评价学生的代码内在质量实例。在SonarQube的帮助下,我们看到了Bob大叔发起的开源项目FitNesse的代码存在哪个主要问题(循环依赖)?

3)金锐主持八皇后问题结对编码操练

总结:

a) 有一个小组,想要一开始就写最优的算法,但是进展比较缓慢。所以我感觉,可以从最笨的方法 -> 改善 -> 改善 ->再改善,才能够达到最优。就好比以前中国人很少排队上车,都一窝蜂地挤在车门口,这样肯定比一个一个排队上车慢许多。一窝蜂地挤上车这一点在做研发时也很常见,项目经理因为贪多贪快,往往把超出团队码农工作“带宽”的工作量,以死亡行军的加班方式让码农完成,最后也是造成“梗阻”,效率反而比一点一点地少量快走的方式慢许多。

b) 用2维数组来表示8皇后的棋盘,有皇后的元素赋值为1,没皇后的元素赋值为0,这样虽然占用了很多存储空间,但是便于写测试代码。即每行和每列的值相加为1,即表示测试通过。若用一维数组存储八皇后(数组下标表示棋盘行号,数组元素值表示棋盘上相应的行上有皇后的棋盘列号),虽然节省了存储空,但是不便于写测试代码。

c) 很赞测试驱动开发的思路,用结果反推方法。只是如何写出全覆盖的测试用例好难哦。可以不必一下子就写出全覆盖的测试用例,这也好比一窝蜂地挤上车。

15位匠友:

遗失的电源线:

抱歉!评论已关闭.