为什么TDD?

1. 反映真实需求

这里存在先写测试和后写测试的区别。

先说后写测试。根据很多经验,在直接写产品实现代码时,需要考虑需求,同时需要兼顾实现的细节,用什么算法和语法。在对需求和考虑和实现细节间来回,很容易让人产生对其中一方的疏忽,遗漏掉一些需求方面,甚至在实现上存在缺陷。

有人会说我可以通过后写测试来保证。第一经验是,很多人都不会在实现完成后,补充测试,因为还有更多的工作和需求需要实现。第二是开发人员很容易在后补的测试中,只是试图去测试他已有的实现,而不是需求本身,很容易遗漏掉一些边界检查之类,在测试时,已有的实现细节会在脑子里面先入为主,即使实现存在问题或有漏洞,也很难在后补的测试中测出来。我阅读过很多面试者的测试代码,很明显都是后补的,因为一些很明显的问题没有测出来,甚至已经实现的逻辑也是只测试了一部分。而这些面试者都承认。

结果就是,一旦代码签入,开始集成之后,暴露出问题,后补的测试起不到对于实现代码的保障需求的作用,开发者不能不借助调试工具,单步跟踪实现代码的每一行去寻找问题发生的原因。

再说先写测试。按照TDD的流程,先写失败的测试,再写恰好让测试成功的实现代码,最后重构,如此往复。这样的好处在于,每先写一个测试,都是在试图用自己对问题和需求的理解,来定义实现代码的架子。从测试的不同角度,范围、边界、大小、功能等等,来定义实现代码将来会是个什么样子。一个测试接着一个测试,利用TDD的过程,把实现代码恰好不多不少,正好驱动出解决这个需求和问题的实现代码来。

这里的重点在于,先写测试可以让开发者把重点放在理解需求和实现需求上,而不是一开始就陷入实现的细节中同时兼顾需求,掉入两者都兼顾不好的境地。先写的测试代码,作为副产品,可以作为验证需求的得力保障。

2. 设计在其中

先写测试对于设计的好处在于,先写测试先定义新的类,以及定义类与类之间的关系,就是在定义类与类之间如何交互,每个类如何暴露自己的接口,类和类之间的引用关系。这时,测试代码会逼迫开发者认真考虑如何分解类与类之间的耦合关系,这样产生的实现代码更容易利用了IoC和DIP的模式,实现面向接口编程。

这样实现代码的好处还在于,代码的可测试性很高,在加入更多的测试代码和新类的时候,同样借力于已有类的面向接口和依赖反转所带来的可测试性,达到新实现代码的面向接口和可测试性,这样进入良性循环。而这对于整体的代码和设计,获益良多。换句话说,测试即设计。

回头看后写测试的情况,因为从一开始开发者把重心放在实现的细节和功能需求的往复上,对于代码设计、类的关系和定义很容易疏于考虑,产生的结果可能是耦合紧,可测试性差。

3. 增强信心

在我看来,软件开发周期、软件交付最大的问题在于交付后的运行和维护阶段,正是这个阶段才是软件在持续交付价值的时期。在软件的可维护性,在这个阶段凸显价值。在软件交付后,包括软件开发周期期间,不可避免的就是开发者在根据新的需求,逐渐添加新的功能代码,或者修复一些已知的缺陷。

很多经验表明,在开发者按照需求添加一些新的代码进入系统,或者试图修复已有缺陷时,很容易导致既有功能出错,也就是新引入的代码打破了既有代码的逻辑,导致回归问题的出现。因为软件系统的可测试性差,无法做到快速频繁自动的回归测试,带来的可维护性自然也很差。

而作为TDD的副产品之一——可以快速频繁自动运行的测试代码,可以在开发者新引入代码之际,给予开发者足够的信心,每次添加一点新代码,一个方法,一个类,都已频繁运行已有相关的测试代码,来确保新引入代码不会打破已有的功能。

在持续集成中,这些测试代码可以帮助验证每次签入的代码都不会破坏掉已有的功能。这也是《重构》里面反复提到的在每个重构小步骤后都要运行所有的测试代码的原因所在。

4. 粒度和进度

按照TDD的原则,先写测试,可以让开发者在同一时间只关注在功能需求的一小部分,把功能需求且分到一定小的粒度,用测试代码去表示这样的需求,用实现代码让测试通过,实现这样的需求,然后重构。

这样的好处在于,开发者自己的注意力和重心不用在整个功能需求内的小需求点之间犹豫,每次注重解决单个小问题,解决完一个进入下一个小问题的解决。在保证小粒度实现的同时,保证进度可以随时被打断,但同时被打断时已经做完的是完整可以运行,至少是实现了部分需求的实现代码。

而后写测试的代价是,首先实现代码很有可能包含设计上的问题,甚至含有缺陷,在完美的测试代码完成之前(事实上这是不可能的),可以交付的是可能存在严重缺陷,甚至是曲解了功能需求的实现代码。

Share
 

前端代码的阻抗失配

Impedance Mismatch(阻抗失配)经常被用来比喻服务器端面向对象代码和关系型数据库存储模型之间的关系,先有ORM技术,后有NoSQL(Document based,Key-value store),都是解决这个阻抗失配的方案。

最近在做的一个项目,具有丰富的前端UI,简单的后台逻辑。应客户的要求,采用ExtJS4作为前端技术,利用它极具交互性的UI和号称优雅的MVC框架,来构造应用的所有页面。

不落俗套,在应用最初搭建阶段,是和ExtJS相处的蜜月期,“优雅”的MVC框架和清晰的封装让人眼前一亮。但是随着项目的进展,在功能需求没有显著增加的同时,客户对于前端交互友好性的需求却与日俱增,不可避免地让前端构造UI及交互的代码日益复杂。

出于面向对象和封装的考虑,对于页面上大大小小的控件,我们基本上都做了封装,而且封装还是嵌套的,在大控件内部还封装着小空间。每一个控件基本上都是满足ExtJS的MVC模式,即对应至少View、Controller两个“类”。

同样出于对架构腐化的担心和对它的不断思考和优化,我们在不断地调整不同类的封装,对事件和行为做一一调整,力争做到合适的封装、减少重复代码、易于理解,从而达到更好的可维护性。

这样最直接的后果就是,在每次我们需要深入代码去解决一些问题时,要费上好一番功夫,从大控件找到内部的小控件,从一个事件发送者搜索到事件的响应者,才能确定出问题的代码可能藏在某个犄角旮旯。

对于封装如此良好、层次如此清晰的前端“面向对象”代码,我的反应开始是:这是否就是解决前端实现或者说架构最优的选择呢?可惜的是,我在Stackoverflow和Delicious上没有找到相似的讨论,倒是发现了很多对于JavaScript MVC的讨论。

以下是我自己的一点想法:

前端代码用ExtJS或者Dojo这样的rich library构建,用程序员惯常的面向对象思维和成熟的MVC架构来实现,无可厚非。但实现的过程与前端页面的渲染并无简单直接的对应关系。程序员在用熟悉的建模和框架时,不会简单地推演出到正在实现的控件及其行为在页面渲染后将以怎样的结果出现。这里需要框架自身的技术支撑和程序员对框架的理解,框架加载脚本的顺序、对MVC实现的风格,不一而足。

浏览器是从页面的开头到结束完成页面的渲染,中间包括脚本的同步或异步的加载,包括框架对于富UI控件的渲染。在页面初始渲染成功后,由框架接手完成未来发生的所有的UI交互,直至页面重新刷新。

如果把浏览器页面的渲染结果,或浏览器内存中的DOM看作是结构、样式和数据的存储,类似于关系型数据中逐行的数据,这与前端实现所采用的面向对象和MVC相对应,同样存在模式的不匹配,即阻抗失配。

不同的是,程序员不用太关心数据库如何存储数据,但不得不清楚不同浏览器如何渲染页面,及框架如何完成帮助后续的交互。

Share
 

Team的一次Code Kata

上周四的中午饭后,我们team坐下来完成了一次Code Kata练习。跟之前的几次邀请PwC team同事过来pair和coach不同,这次是我们组自己内部完成一次练习,题目来自Yuheng之前的一个练习:文曲星上的猜数字游戏。

题目规则很简单:

  1. 游戏开始后,系统会随机给出四个不重复的数字。由用户输入自己猜测的四个数字。
  2. 如果数字猜对而且位置也对,就是1一个A。
  3. 如果数字猜对但位置不对,就是一个B。
  4. 返回结果是如“2A1B”这样的字串。
  5. 猜错6次,游戏提示结束。重来。

开始提出的要求简单:用TDD驱动出实际代码。

大家抽签后开始pair,Yuheng还会一边计时一边催促,pair的气氛基本保持紧张有序。

在我和XuChen pair开始代码后,我们很容易写出第一个测试1,期望返回结果是”4A0B”,最简单的代码实现让测试变绿。

当我们试图写下第二个测试2,试图期望返回结果是“2A1B”时,我们发现不得不面对如何这个游戏规则的最核心算法,但可惜的是,猛然间对这个算法没有头绪。

局面一时僵住,停顿了有两分钟。

直觉和一点经验告诉我们,这时该拆解任务了。很容易想到,如果计算出几个A和几个B是很直白的拆分。

我们可以很容易写出一个测试3,测试猜测的四个数字跟事先给定的四个数字相比,有几个A类数字(循环比较),我们称之为perfect number。

也很容易写出另外一个测试4,测试猜测的四个数字跟事先给定的四个数字相比,有几个B类数字(在上个算法的基础上再循环比较),我们称之为good number。

写完针对测试3和4的实现代码,我们发现我们已经完成了最基本的算法,功能完成了。剩下的是重构代码。

从我们这次的经验看,我有一些收获和心得:

  1. 测试就是代码的设计,你看测试3和4导致的结果就是我们有了对应的两个计算方法。你打算怎么测,你的实现代码就会是怎样的。
  2. 印证了在Wikipedia中那段话,pair programming尤其适合面对一些challenging的任务(至少开始的时候是)。
  3. 分解任务是王道。我们在不同的level拆分任务,从story拆分成task,从大问题拆分成小问题,莫不如是。
  4. 囿于经验,不期望由端到端的测试能逐步甚至一下子推导出完整、完善的代码实现。而这样的练习,恰恰是我们锻造自己经验必不可少的过程。

我们在实现代码时,仍然欠缺的是:

  1. 对于测试方法名的命名,不够清晰直白。
  2. 对于算法代码的实现,简单粗糙,还需要重构。
Share
 

为什么要结对编程?

以下内容摘自myThoughtWorks中对于结对编程(Pair Programming)的讨论。

结对编程与非结对编程相比那个效率会更高?

这个问题没有一个明确的答案,没有人可以很肯定的说结对编程就是会比非结对编程更有效率。效率不单单是时间,还包含效果。

如 果对于一个技术难度不高,一个人几天就可以搞定,后期不需要维护的一个小项目来说可能结对编程在效率上会低于非结对编程。但是我们twer是关注代码质量 的,面临的项目一般都是需要持续发展,而且是具有一定规模的。对于这样的项目和我们,从长远来看,结对编程会带给我们长足的发展和更高的效率。对于这点我 总结了如下几点(欢迎补充):

  1. 代码质量。结对编程与非结对编程相比,往往更加容易写出更短 的代码,做出更好的设计,产生的更少的bug。俗话说三个臭皮匠顶过一个诸葛亮,每个人的思维 都是有瓶颈的,两个人的合作通常会考虑更多的设计选项,达成更简单,更易维护的设计。研究发现结对编程bug率降低会15%到50%,这个会根据程序员的 经验以及任务的复杂度而不同,这样就会大大减少以后修bug的时间,降低维护成本。这样我们才敢一个项目只有一个QA或者没有QA呀!
  2. 互相督促。 在结对编程的过程中我们可以相互督促,比如严格去TDD减少裸奔,提高注意力避免一个人注意力不集中或者花时间上网处理个人事宜,避免偷工减料 等等,从而也可以在某种程度上保证我们的代码质量。而且人们更不愿意打断两个结对编程的人,而单独工作的人却容易被打断,这样也增加了我们专注工作的时 间。
  3. 知识共享。在结对编程我们是知识共享的,还有我们会不停的switch pair,轮流与团队中的所有其他程序员结对编程,而不是仅与某个程序员编程,使得系统的知识在整个团队中传播,减少了程序员休假或者离开团队带来的风险,从而可以保证我们项目的可持续发展。
  4. 新人成长。 这是结对编程很重要的一个作用。曾经听大大说过,他和大熊发现,在别的公司毕业刚刚一年的毕业生在项目中可以承担的还很少,但是在我们公司很多 人已经成为了项目的骨干。这很大程度上要归功于结对。当新员工进入一个项目的时候,我们往往会安排有经验的老员工去跟他们结对,这样新员工可以更快熟悉项 目情况,更快的进入状态,更快的发现自己的不足,也可以学到更多的东西,更快的成长起来为项目做出贡献。
  5. 沟通能力。结对编程需要两个人一起讨论,一起把一件事情做完,也是对我们沟通能力的一种锻炼。让我们不再是很多人眼中只会闷头写代码的木讷的程序员了。
  6. 结对可以省钱http://www.infoq.com/cn/news/2009/06/dollar-value-of-pair-programming
  7. 徐昊说结对还可以Simple Designhttp://blog.vincentx.info/2007/03/agile-101-pair-programming-simple-design/
Share
 

2011 ThoughtWorks烽火传奇

Chapter1

树林外传来密集的枪声,由远及近,渐渐清晰。 山顶树丛后,迷彩的掩护下,几道焦急的目光投向了中心处的一位彪形大汉。

张凯峰队长抬手擦了擦额头上混在一起的血和汗,心中暗暗叹了口气,从枪声判断,敌人距离这里已经不远,这也就意味着一队高队长和二队月队长的防线已经溃败。时间已经不多,是时候来做最后的诀别了。

队长慢慢的抬头,沙哑的声音从干裂的嘴唇中缓缓吐出:“同志们,我想大家都明白,防线已被攻破,我们此次的失败已在所难免。”

说到这里,队长艰难的停下来,重重的喘息,仿佛“失败”二字就已经给了他巨大的负担。

身边的战士有人紧咬着嘴唇,有人摘下军帽,死死地攥在手里。

张队长用目光在所有人的身上环视一圈,然后继续开口:“很不甘心,是么?我也一样啊!一想到圣教的火焰或许会在此处熄灭,我的心就像被剖开一般疼痛。试问,还有什么,能比失去光明的指引更加痛苦!!!”

这样沉重的话语带给人们的是更深刻的悲痛,几个女孩子已经把持不住,相拥在一起低声的啜泣。

“但 是,我们的使命还未完结,如果死亡是我们注定的终结,我愿让这终结如烟花般绚烂,将我们不屈的斗志传达,哪怕只有一瞬间,也要照亮这黑暗的世间!!!同志 们冲啊!!!!!”张队长站起身来,大手一挥,从树丛中一跃而出,向着外漫山遍野的蓝色敌军冲去:“我愿将此身化为碉堡,在死后仍能为同志们挡去敌人的子 弹!日月神教!千秋永存!!!”

“啊啊啊!冲啊!!!”紧跟着张队长,付莹参谋也迎向了敌军。

“铁甲依然在~ ”江荣冲出去了。

“我们的敌人必将被消灭! ” 李斌冲出去了。

“女性!荣耀!梦想!”四眼冲出去了。

“啊啊啊啊啊啊~~~~~~”张桐也冲去了。

一点一点绿色的身影冲向了蓝色的防线,就像明亮的火焰冲进蔚蓝的大海。

这就是惊天动地的首次2011新员工真人CS第一战,史称红螺寺山体攻防战中,最为悲壮的一刻!天地为之变色,草木为之含悲,日月神教永垂不朽,荣光与我们同在!!!

 

Chapter2

天堂里,一群绿衣服的家伙蹲在地上,在角落里围成一个圈。中间还是我们熟悉的张队,正不耐烦的捻灭一只烟:“别吵别吵~ 死都死了,还不冷静。我们现在不是要推卸责任,而是要吸取经验,总结教训,从根部开始,源头开始,上起祖宗十八代,下数华夏五千年,深刻挖掘这次战争失败原因!怎么着我们就输了呢?!”

“老 大,我先说!”二队的月队长率先起身,“我们的敌军既优秀又强大,有三成以上以前就参加过各种战役,有着丰富的经验,是我们所不能比拟的。而且此次战役 中,敌军又启用了先进的生化武器,将徐晨,侯斌轶改造为僵尸战士作战,无法杀死。从而轻而易举,气势如虹的击溃了我们的防线。老大您明鉴,不是兄弟们不努 力,实在是敌军太狡猾啊!”

“去 去去,你这是给敌人开表彰大会呢吧!”张队长哄蚊子似的摆了摆手,“什么敌军太狡猾,分明就是我军太失水准。就说小月月你身为二队的队长,为了拉风非要穿 一件桔黄色的衣服,在绿色的树林里走到哪里都是活动靶,开场没三分钟就挂掉了,严重影响了我军的正常战略节奏,是导致最后失败的罪魁祸首。”

“所以说不怕神一样的对手,就怕猪一样的队友。”角落里,平素最爱吐槽的四眼儿政委接着张老大的话茬,持续进行毒舌攻击。

“你也好不到哪儿去!”张老大没好气的开始数落小政委,“在背后开冷枪误伤一个顶仨,真正面对敌人了,子弹射程还没有唾沫星子喷的一半儿远。一场下来三条命全送出去了,可一枪都没打到敌人!”

听到老大点名自己,四眼哭丧着脸站起来:“老大,我我我,我错了。同为政委,蓝军的Magen那是战神加护雅典娜附体,上场先杀死4人。我是刚刚亮相就被人乱枪打死。我愧对祖国愧对党。为表羞愧之心我决定以死谢罪,大家你们都不要拦我啊啊啊~”

说罢,四眼儿政委不知从哪里变出一根半指来宽的麻绳,笨手笨脚地在身旁的歪脖树上打了个圈,抻着脖子想把那颗大脑袋套进去,作势要去见马克思。

“算了算了,又不是盗梦空间,你当能在死亡状态下再死二回啊。”张队长最不待见这种苦情戏,赶紧招呼旁边的娴静军长把四眼儿拦了下来。

几个人七首八脚的把四眼弄下来,这才发现不知什么时候起,四眼儿已经进入了发呆状态。张队长心说不好,该不会是刚才批评的太狠了给小孩儿整自闭了吧。

众人正琢磨着要不要弄个电击疗法刺激刺激四眼儿政委的时候,这边四眼突然大叫一声:“我知道了!”然后从地上一跃而起,跑到张队长面前,一把拉起张队的手:“队长,我知道了!我可以先复活,这样就可以继续死了。”

“额?你是说我们可以复活?”张队长问道。

“是啊是啊,队长你没听过信春哥死后原地满血满状态复活的!!”小政委乐颠颠的说。

“哇呀呀呀呀~ 有这等好事,那还等什么?!”张队长一把抄起地上的抢,举起高呼,“小的们,跟着我,复活继续跟他们拼一场啊!!!!!!”

 

Chapter3

“怎么又死了呢!!”张队长的咆哮惊走了山林上飞禽走兽,“你们不是自称攻无不克战无不胜全灭敌军胜利手到擒来的无敌日月神教么!!!!!!怎么水平一个一个的比我还菜呢?身为军人却大脑壳小细脖还全带着眼镜!我要去军事法庭投诉征兵水平!”

“队长息怒,”旁边的杨锐狗腿的凑了上来,“虽然我们的战斗力可能有一点点的不够合格,但是我们这次从教官那偷来了秘密武器,你看~”说罢,神秘兮兮的从背包里掏出一个黑色物体。

“咦?复活遥控器!” 九强凑了上来,一看是好东西,两眼放光的在杨锐肩上拍了一下。

“老大,据说只要我们队里还有一个人活着,就能用这个遥控器无限次复活队友。” 胡悦也凑过来,献宝似的说道。

“哇哈哈哈,这次我们就无敌了!”终于得到了终极武器的张队长双手叉腰,仰天大笑。

“队队队长~~不好了!!”那边还没笑完,这边四眼就上气不接下气的冲了进来,“队长!龙珠队杀回来鞭尸了!”

话音未落,只见蓝队的先锋史磊和文迪踢开房门冲了进来,紧接着龙珠队长唱鑫一袭蓝衣飘然而至,后边跟着小虫、庆法、王健、王彪、徐晨、魏广程等众人。

但见狙击手肖然抬手一梭子弹打在唯一还生还的张队长身上。只听“啊~”的一声惨叫后,绿队里最后一个幸存者也被记入了死亡名单。

“我死不瞑目哇~~~~”张队长的怒吼声,伴随着落日的余辉,缓缓沉入地平线下。

Share
 

Mock, Stub, Fake

上次郑晔给大家做游戏,徐昊问到台上的咨询师,Mock、Stub和Fake的区别是什么?

自己虽然心里有点印象,但还是下来搜了一下:

Wikipedia的解释是这样:

Some authors[1] draw a distinction between fake and mock objects. Fakes are the simpler of the two, simply implementing the same interface as the object that they represent and returning pre-arranged responses. Thus a fake object merely provides a set of method stubs.

In the book “The Art of Unit Testing”[2] mocks are described as a fake object that helps decide if a test failed or passed, by verifying if an interaction on an object occurred or not. Everything else is defined as a stub. In that book, “Fakes” are anything that is not real. Based on their usage, they are either stubs or mocks.

Mock objects in this sense do a little more: their method implementations contain assertions of their own. This means that a true mock, in this sense, will examine the context of each call— perhaps checking the order in which its methods are called, perhaps performing tests on the data passed into the method calls as arguments.

这里还有StackOverFlow的回答

扩展阅读:

Share
 

SAI项目小结

其实这个我在TW的第一个项目还没结束,现在就总结还为时尚早。但我担心我会遗忘,而且既然有心思写下来,为什么要等那么一个时机呢?

  1. JS代码组织结构和单元测试。按照客户要求,我们使用SmartClient作为客户端RIA库,这个库的优点是丰富的UI控件,但逻辑和视图耦合很紧。当我们发现JS端代码日渐庞大臃肿时,耦合紧导致维护很难,而这时已经过了第一个Release。在第二个Release中,我们讨论过用MVP来解耦,引入Jasmine作单元测试,讨论尽可能将代码做M、V、C三个角度分离并有了尝试,但仍未引起足够多的重视。我们是侥幸的,因为这个项目并不复杂,不管从技术上还是业务上,所以这个方面的技术债感受不深。我们知道我们应该做的。
  2. 代码静态分析和质量控制。我们直到第二个Release的后期,才试图引入cobertura和sonar来分析我们的所有代码,结果可想而知,一些测试没有覆盖,代码的逻辑有问题,有些是多余的分支,有些是永远不会走到的逻辑。这样又方便又能让我们学习的工具,为什么没能早点采用呢?
  3. 成熟框架。因为Team半数以上是新TWer,从一开始team并未引入Hibernate和Spring等重量级框架,但在Domain Model分析上下了功夫,这样一直平静发展到Release 1结束。Release 2开始,因为团队学习的需求和客户要求架构统一,我们同时引入Spring和Hibernate,用到的多是框架最核心和基础的技术,除了遇到个别问题比如双向关联、继承和Proxy Bean,一切都还正常,业务和技术的双重相对简单性决定也用不了多复杂的框架技术。只是在临近Release 2结束时,客户要求集成双方的系统时,我们发现引入Hibernate和Spring在这时是一种风险,或者说累赘,我们不得不合并或者修改一些配置,以期避免冲突,这个过程不那么平滑。
  4. 代码合并。最后关头时间紧,我们却发现我们要merge一个超过一万两千行代码的类,这个类基本是一个Release才merge一次。过程痛苦,IDE自作主张的分析合并让我们无法相信它,我们能做的只是纯文本的手工对比,这时Beyond Compare帮了大忙,但即使这样也消耗了我们近半个下午的时间,这还只是不到十个类文件。我在想,如果能前瞻一点再果断一点,我们定不会在这个一万两千多行的类里面再添加我们全部的实现的代码,而是挪到自己的实现类里。
  5. 管理客户期望。系统集成,是客户在Release 2还剩一个半迭代时,强烈提出的。这个问题似乎从项目开始时可以预期,甚至中途客户也是偶尔提及,但我们似乎没有足够重视。我更认为这是业务理解和管理客户期望的问题。我还没有更好的想法,期待跟团队一起回顾。
Share