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

时间：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位匠友：

遗失的电源线：