所有由张凯峰发布的文章

张凯峰

关于张凯峰

ThoughtWorks程序员,InfoQ中文站编辑,有多年软件开发和测试经验,热衷参与技术社区与技术传播,参与翻译《Ajax实战》、《开源技术选型手册》。

2011 ThoughtWorks烽火传奇

Chapter1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Chapter2

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Chapter3

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

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

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

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

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

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

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

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

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

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的回答

扩展阅读:

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还剩一个半迭代时,强烈提出的。这个问题似乎从项目开始时可以预期,甚至中途客户也是偶尔提及,但我们似乎没有足够重视。我更认为这是业务理解和管理客户期望的问题。我还没有更好的想法,期待跟团队一起回顾。

ThoughtWorks有什么不同?

仅仅入职两个月时间,就试图看清楚说明白新入职公司的不同,注定是浅陋的。但是这并不妨碍我说出目前我心目中的ThoughtWorks。

昨天和前同事聊天,被问起了ThoughtWorks跟之前公司有哪些不同的地方。我想了想说,你所知道的敏捷的全部,在ThoughtWorks都能找到;没有拖沓碎叨更像是status update的standup; 我看到了自组织的团队,每个人都在团队中承担自己的职责,自信且淡定;扁平的层级文化,没有看不到头的title层次,可以把精力聚焦在项目上和自己感兴趣的事情上;可以向整个公司发邮件,表达自己的担心和困惑,评论社会现实,公司的老大也会加入进来讨论;可以让自己承担起公司主人的角色,为公司的发展做出自己的努力和影响;还有ThoughtWorks对于利用软件和技术改善人类生活的社会责任的担当;ThoughtWorks一直致力于用最先进的技术和方法来帮助客户,这会让做技术的人很high。这些在别的公司都是很难见到的。

我之前的工作经历很有代表性,先是一家国内大型软件企业,然后是一家大型外资企业,这样的经历让我有在不同企业背景和文化下的体验,也让我现在有了相对的参照系,来比较现在所在的环境——ThoughtWorks有什么不同。

如果答案仅仅止步于上面那些不同,我想这是肤浅的。是什么造就了这些以及更多的不同?有一些线索可以帮助理清楚:

在TWI上徐昊提到了Martin Fowler写的一篇博客,讲的就是ThoughtWorks是Roy的社会化实践。Roy希望借这场实践来证明那些认定下面结论的观点是错误的:

  • 你的公司不可能只由能力强的人们组成,必须存在能力差别
  • 能力强的人往往无法合作
  • 大型公司必须有强有力的管理结构,以避免分崩离析
  • 不可能为考虑长远而做事
  • 成为国际化公司是为了利用欠发达国家的人才
  • 不能暴露自己的弱点,尤其对于公司外
  • 不要赋予员工权利,否则会被滥用而伤害公司
  • 文化是次要的,你需要一个优越的商业模型

“社会化实践”,是不是挺震撼的?事实是,ThoughtWorks的确在全球网罗到了一批才能很高的人,在共同致力发展这个公司,守护这样的文化。我们成为了Roy的实验品,但软件这个特殊的行业,工程师这个简单又复杂的职业,这样一群人,的确在印证着Roy的实验趋向成功。

另外还有一篇文章《为什么我要把公司做成扁平型》,作者是37signals的创始人之一,他讲述了公司确实发生过的事情,当试图为一些资深员工创造一个管理职位和职务来发展时,遇到的问题和冲突。经验证明,让团队自己管理自己是效率更高的方式,因为的确有这样的一些人,不介意有那样垂直发展的梯子供自己攀爬。

最后是今天看到的米高写的一篇《全面成功》,这跟我在团队同事那里听到的一样。怎样定义项目的成功,只顺利结项拿到款是肤浅和单薄的。客户满意,项目质量高,团队得到发展,不一而足。ThoughtWorks的文化追求,也导致了全面成功是每个项目组的诉求。在这样的环境下,团队才会是自组织的,个人最后也才是充实和成功的。

Experience Design初体验

打酱油的结果,就是有机会两次经历ThoughtWorks的Experience Design。一次是针对Climate Action的Social Impact Project,一次是Beijing Design Night。

在过程中,我领略到了跟之前的经验和了解完全不同的设计体验:如何拨开层层需求迷雾,抛弃虚妄的需求,找到潜在系统用户的真正痛点,实现和改进系统的功能,提升用户的内在体验。

我们会首先设计出目标系统的使用者——Persona,一个虚拟的用户,但有明确的生活和职业背景。

然后是依据这个Persona设计他/她的Empathy Map和User Journey。会根据模拟和假设Persona的所听所见所闻所想来发现Persona对系统的(甚至是潜在的)期望,模拟一个尽量真实的故事历程来找出Persona的痛点,从而找到可以实现和改进的地方。这个设计过程是整个团队和客户共同参与,进行头脑风暴的过程,合作的过程可以避免对Persona的误解以及以偏概全。

最后会用笔和纸快速地在纸上画出Sketching,也就是UI的原型,充分体现出设计过程产生的系统改进并解决痛点。

Experience Design会是ThoughtWorks未来很重要的一个Offering。

扩展阅读在这里

ThoughtWorks需要怎样的人?

想知道如何才能做好软件的人
想学习最新前沿技术并应用在项目中的人
想在项目中自己做主承担责任的人
想跟大牛成为同事一起工作的人

厌恶大公司繁文缛节的人
厌恶低效无谓加班的人
厌恶没有进步空间的人
厌恶盛气凌人的老板的人

想用上最新版MacBook Pro甚至Air的人
想每天吃到新鲜水果喝可乐的人
想每天可以打PS3和街机的人
想每天都有session听的人

不想把薪水放在第一位的人
不一心追求升职的人
不沽名钓誉的人
不畏惧变化的人

DevOps之Puppet

Puppet在一款自动化系统配置管理的工具,它可以让你在很短的时间内对大量硬件和系统基本类似的系统,进行统一的系统配置管理。

说的简单点,就像开网吧,你需要对网吧的每一台机器安装操作系统,配置完全一样的软件,比如QQ和360,供网友上网,在系统和软件有损坏时,很简单的一个恢复操作就可以让机器回到刚刚安装好操作系统和软件的状态。

Puppet就是可以干这个事儿的,不同在于,Puppet是给网络管理员用的,而针对的系统多是*nix系统,因为Puppet目前对Windows支持的很少,但这不妨碍Puppet成为DevOps实现过程中的利器,另外一个类似的工具是Chef

Puppet本身基于Ruby实现,但即使没有Ruby的经验也没甚大碍。Puppet自己提出了所谓Puppet Language,是一种DSL(Domain Specific Language)语言,用直白而描述性的语言,定义系统应该具有的状态,比如一个简单的例子tmpfile.pp:

file { 'testfile':  
    path => '/tmp/testfile',
    ensure  => present,
    mode    => 0640,
    content => "I'm a test file.",    
}

在安装了Puppet了机器上运行:

puppet apply tmpfile.pp

结果就会在/tmp下新增加一个testfile,内容是This is a test file。
这个例子太简单。除了file这种类型外,Puppet提供了大量的资源类型,供对系统的状态进行描述,比如打开(如果不存在会自动下载)某项服务,自动增加一个用户。当管理的机器成百上千,这样的自动化服务达到的效果就很可观了。

puppet apply是Puppet在单机上运行和测试的工具,真实的使用情景会是,一台机器(master)专门保留所有机器配置管理的状态信息,而每台机器(agent)会在指定的时间向master发起查询,从而更新自己的系统状态,以期与指定状态保持一致。

 

 

DevOps是什么?

DevOps是什么?

devops is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

— from Wikipedia, http://en.wikipedia.org/wiki/Devops

简单的说,DevOps是一组原则、方法和实践的集合,用来改善软件研发和IT运维之间的沟通、协作和集成,从而让软件产品和服务以更快的速度发布。

这里的快不是真正的目的,真的目的在于终端用户不会察觉到快速交付带来的不爽(质量、性能、安全性变差),而是享受到版本变化带来的更优质服务,这样才能让软件企业立于不败之地。至于为什么要快,我不说,你懂的。

一边要快,一边要稳定。说到稳定,就没法把运维避开不谈了。所以DevOps就是试图消除软件研发和运维之间的壁垒,让二者结合为更高效的软件交付团队。

DevOps涉及到什么?

DevOps是基于Agile的理念,并试图用Agile去影响其他部门、团队和实践。这里涉及到Agile和Lean中各式各样试图提高效率、消除浪费而采取的过程式、理念式、工具式的实践。可以包含但不限于以下内容:

  • 让开发人员和运维人员交叉参加部门会议
  • 让开发环境与运维环境保持一致
  • 自动化任何运维过程可以自动化的过程

如果有人或者公司说,用了我们的blabla产品,就是DevOps了,这只会引来明白人的窃笑。这个效果,基本和说我们每天都Stand Up所以我们就是敏捷也可以跳舞一样可笑。

在我看来,实施DevOps最后要面临和解决的依然是组织和人的问题,这是文化和价值观信奉的差别,与具体的产品和项目无关。我甚至预见,DevOps因为会涉及到不同业务部门,而不像敏捷只会局限在研发单一部门内,反而更难实行。所以,可以想象,在怎样的情形甚至逼迫下,会有怎样类型的企业会去追求真正意义上的DevOps。

扩展阅读:

IFrame带来的Session问题

客户原来有个Web App系统A,我们要基于A开发一个系统B,但不希望B对A依赖太重,所以B被实现为一个独立的Web App(war)。A和B部署在同一个Weblogic server上,在A中可以导航到B,两个系统看起来像是一个系统。

有个小需求是,在B中希望显示一个页面,根据参数能展示出不同的信息。这个页面在A中已经存在,所以自然而然最快的方法就是在B中创建一个iframe来指向那个A中的页面,配以不同的参数,多快好省!

问题很快出来了,QA发现那个iframe中的A页面很快就会session timeout,然后会提示用户输入登陆用户名和密码,而iframe外的B session并未过期的。

问题在于A和B实际上还是两个Web App,各自有各自的session。因为不能简单地修改A的页面,让它保持session不会timeout,所以剩下的办法只好是控制B的session timeout时间要早于A了。还有什么更优雅的方法呢?

如果给我一次重新实现的机会,我宁愿自己画一个属于B的页面,而扔掉iframe。

另外一个需求是,A和B是各自独立的Web App对于用户是透明的,用A的用户登陆进来可以直接进入B,反之则不可以。解决办法有点tricky,A的contextRoot设为/,B的contextRoot设为/XXX,这样二者的servletContext为同一个,即可实现A把自己的loginToken放到servletContext中后由B访问到,从而在请求B页面时,检查是否能取到servletContext中的loginToken,如果不能则转向到A的登陆页面,这点由Filter来实现。

事关挪卡(Moving Story)

最近我的team频繁遇到关于挪卡与否的事情。

可能会包括下面其中一种情况:

  1. 一个Story在前一个迭代做完了,但是客户没有及时sign-off,导致后一迭代中客户发现Sotry实现有问题,不是自己想要的东西,需要重新实现。
  2. 一个Story在前一个迭代做完了,客户已经sign-off,但在后一迭代中我们发现实现中设计有问题,会引发其他的bug。
  3. 一个Story在迭代中实现完毕,进入In QA,但发现有重要的AC没有事先提出来,导致需要补充实现。

可能还会包括其他可能的情况,不一一列举了。

我们team的对策分别是:

  1. 新开一个Story卡,对有问题的部分重新实现。这里的问题在于没有及时从客户那里取得反馈,原因自然有多种,你懂的。
  2. 新开Defect卡,对发现的问题进行修复。
  3. 直接在当前迭代中,把Story卡挪回In Dev,补充实现。但不会修改点数。

this in Selenium’s get_eval() method

At Selenium Ruby site, there is a description for method get_eval(script), as following:

Gets the result of evaluating the specified JavaScript snippet. The snippet may have multiple lines, but only the result of the last line will be returned.

Note that, by default, the snippet will run in the context of the “selenium” object itself, so this will refer to the Selenium object. Use window to refer to the window of your application, e.g. window.document.getElementById(‘foo’) If you need to use a locator to refer to a single element in your application page, you can use this.browserbot.findElement("id=foo") where “id=foo” is your locator.

The special thing here is the this reference, means when invoking method get_eval() to run some javascript snippet, the this reference in snippet would refer to (redicted?) caller Selenium object but not the original belonging object.

This does differ from what we already know for window.eval() method, in which javascript snippt this still refer to the original belonging object, see below demo code:

var a = 0;
window.eval("this.a = 1"); // this refers to window object
alert(a); // a=1
alert(this.a == a) // true

Above code demos this is window object itself.

function A(){};
A.prototype = {
  f1: function(){
    return "f1";
  },
  f2: function(){
    alert(this.f1());
  }
}
var a = new A();
window.eval("a.f2()"); // equals to a.f2(), this in f2 refers to a.

Above code demos this in a.f2() method still refers to a, but not window object.

Generally, eval() is an evil thing.

OO训练营第四五课

徐X语录:

Design Pattern是针对特定问题的特定解决方案。

是问题,而不是解决方案定义了Pattern。

模式之间存在相似性,比如Adapter和Bridge模式,只是量的差别。

先让问题再想着怎么解决 over 想清楚什么问题再下手。

面向接口编程破坏了Communication和Technical之间的平衡。会带来Communication debt。

真的需要抽取借口时,需要两个条件:1. Concret Class;2. Consumer for Interface

没有bad smell就不要重构。

Pair的节奏

这篇只想说说我对Pair节奏的理解。

Pair是需要节奏的,为什么?最简单的回答是,没有节奏,两个人都会很累。我有体会,跟team另一个新TWer一起pair,两个人会不由自主地坐在屏幕前,切分任务,你写测试我写实现,一动不动坐了整个下午,除了上厕所的时间。可想而知,离开办公室的时候那个疲惫。

不是说Pair就会比一个人“裸奔”轻松,恰恰相反,Pair就会比较累,这是无数人经验证明的。但是我们仍然需要在Pair时控制一定的节奏,不仅仅是为了减轻疲劳。

最直觉的反应是,疲劳会影响对问题的考虑,测试的覆盖度,代码的质量,这在一对Pair都疲劳的状态下,也不能免俗。当疲劳把Pair能带来的那些个好处统统赶跑后,Pair还有何存在的意义?

一般来说,对Pair经验比较少的人,节奏可以由Pair经验多的人来控制,如何划分任务,粒度以及驱动测试开发的频度如何,都可以依据Pair的双方的能力和经验对比进行安排。在划分任务和思考时,可以以提问的形式,互相提问回答,推动进度。实现代码时,可以以乒乓的形式,由一方来编写测试,另一方编写实现,并跨任务轮换,让双方都感觉到Story的实现在有条不紊地前进,充满自信。双方可以约定在一个小时左右的时间,进行一次短暂的休息,切换context,以确保有持续的精力投入后续的Pair。

因为Pair是两个人的事情,当一方因为某种原因感觉到疲劳,或者被第三方事情打扰,不能集中精力在pair中时,可以主动跟对方提出中断,以换取集中的注意力在Pair上。

如果Pair对于某个问题或技术都不熟悉,并且在可遇见的时间内无法解决,应该立即寻求有经验同事的帮助,或者暂时放下留待后期解决,坚持钻牛角尖无疑是破快Pair节奏的杀手之一。就我的经验看,Pair时钻牛角尖的几率很小,在一方出现端倪时,对方会明显感觉到并主动提出来跳出这个圈子,这应该时Pair时一个小小的好处吧。

至于可能破坏Pair节奏的另外一个杀手——两人就问题或技术有争执,一般会发上在没有较多Pair经验的人身上,这会是另外一个话题,涉及到Simple Design,徐叉教导我们,要用代码证明自己的观点,要反过来关注问题本身。

Pair时的心态

为什么我们需要pair programming,以及pair有什么好处,不是这篇文章要说的内容,关于这些方面,网上能找到的太多太多。这篇只是想说说对于pair中心态的问题,我在pair时的体会。

对于有过开发经验的人来说,离开几年来一直专属自己的那个格子间,坐到一张开放会议桌边写代码,旁边还坐着自己的pair,度过半天甚至一天的开发旅程,并不见得都是一帆风顺的过程。

每个人有自己的开发经验、背景和知识,成为pair就要为Story的代码质量负责。怎样合力以解决问题产生代码,是需要彼此Open心态,针对问题解决问题,而不是:

  1. 妄自尊大,容纳不下对方的观点
  2. 对对方不闻不问自顾自操作机器
  3. 炫耀自己的知识面而鄙视对方
  4. 甚至出言不逊,伤了对方还浑然不知

这是一个成长的过程,也是一个自我剖析让自己更open的过程。所以我们一般会安排由具有丰富pair经验的老同事带着新同事一块来pair,还会有乒乓和keyboard-mouse方式来控制pair的节奏。在知识传递的同时,逐渐打开每个人闭锁自我的心态,逐步提高pair的效率从而提高team的velocity。

从小处看,这是个人心态改变的过程,从大处看,这是开发文化不同导致的诉求。

Automation Training For TW QA

今天作为酱油党之一(徐X语,还有小刀和LeoShi同行)参加了徐X为TW QA开的Automation Training。

对于Ruby小白的我,跟着QA一起学了一把。

  • Ruby的包机制,应用的配置环境
  • Selenium RC的原理,包的四个变种。
  • 在07年就提到过的Page Object

自动化测试具备怎样的特质,才能最大限度的减少QA手工测试的工作量?

  1. Effective
  2. QA manageable

最后,徐X介绍了几个月前他研究出的Data Flow大法。简言之,测试不是要去测试事情本身,而是要测试事情结果的确发生。听着象废话,但那张精美手绘图却惊艳得不行。用以作为切分并归纳测试案例的依据。很受用,争取撺掇一篇文章出来。

OO训练营第二三课

这两节课徐X给出的问题是,用代码表达在停车场停车的模型和逻辑。

首先,还是任务分解。分解出任务列表的样子,取决于对程序架构的理解。理解不同,导致划分出来的任务列表也不一致。但要保证每个任务能够衍生出1-2条可以测试的子任务,变成代码。对于测试任务的设计,既可以从状态变化上来考虑,也可以从行为上来考虑。而且,由分解出来的任务列表,可以反推出需求是什么。

课上有一对pair最后没有完成测试及实现代码,原因在于双方对各自的实现方案争执不下,被徐X拿来教导我们:在这种情况下,要放下争执,去还原真实的业务场景和需求是什么,来解决实际的问题。

总会有分别都是正确观点的双方在争执,就像民主之于正义。这个时候我们要evidence over opinion,通过代码来表达自己的观点。

最后,徐X再度施展重构神技。