Monthly Archives: October 2010

[Defect Identification] 两件事先后发生,不代表两者有因果关系

两件事先后发生,不代表两者有因果关系。

这简直是废话,但在处理古怪缺陷时我们常常会忘记这一点:

  一拉电灯线房子就倒了,我们很容易就以为是房子是被拉倒的;于是百般分析电灯线和房子之间的力学关系,直到多年后有个人在外国出了一本回忆录,回忆录上说他当年是怎么挖地道偷渡的。

[Apache Commons]ToStringBuilder的几种ToStringStyle

老是记不住,干脆把它们抄到博客中来

1. DEFAULT_STYLE

   Person@182f0db[name=John Doe,age=33,smoker=false]

2. MULTI_LINE_STYLE

    Person@182f0db[

   name=John Doe

   age=33

   smoker=false

]

3. NO_FIELD_NAMES_STYLE

   Person@182f0db[John Doe,33,false]

4. SHORT_PREFIX_STYLE

  Person[name=John Doe,age=33,smoker=false]

5. SIMPLE_STYLE

   John Doe,33,false

项目管理体会之二:写完长篇大论的邮件之后,稍想一下再发

如果你要发出的邮件是长篇大论,那就不要急着马上发出去:

 

   1.篇幅长的文章难免会有错别字、语法、通顺等问题,最好再重读一遍自己的邮件再发出去。

   2.写邮件前你有五件事要说,但写着写着,到最后可能会漏掉一两件事,因为遣词造句需要高度注意力,可能会搞得你忘了一两个要点。 所以写完邮件后,再稍微想想,自己的文章是否完整。

项目管理体会之一:高风险的事情要反复核实

机器不会犯错,人则容易犯错。人会健忘和粗心。

项目管理的工作之一,就是克服人类的这些缺点,使之像机器一样严谨。

在处理高风险的事情时,更要注意这一点。

具体来说:

   1.与日期/时间有关的事情是风险比较大的,这种事情一旦弄错,搞得合同出问题,那所有的辛苦都要白费。所以
对日期/时间要反复核实,不但要拿到口头的消息,还要尽量拿到书面确认

   2.
一些高风险的任务,只发邮件是不够的。 而是一定要面对面或者电话说一下,得到对方的实时反馈方可。

看了一篇文章《Pair Programming的 Costs/Benefits 分析》

文章的原名是 ‘The Costs and Benefits of Pair Programming’, by Alistair Cockburn & Laurie Williams

这里把最后的Summary摘录一下:

成本:据研究,
开发时间并不会增加一倍,而是增加15%; 并且这
增加的15%的时间会在以后的阶段省回来(如测试、维护、客户支持等)

收益:很多。

   1. 在开发阶段就发现问题。这种问题比在QA阶段发现的问题更容易解决。

   2. PP实际是持续的代码检视。这种持续性可以使缺陷率更低。

   3. 设计会更好,代码会更简单。

   4. 解决问题 的效率会提高。因为多一个人就会多许多思路。一个典型的例子就是:在研究难查的Defects时,两个人会比一个人更有灵感。

   5. 互相学习。既学习设计与编程,还能学到有关系统的知识。

   6. 由于知识共享的程度比较好,即使核心工程师走人,项目也没什么风险。

   7. 大家水平普遍提高, 团队的工作能力提高。

   8. 一起工作,铸造团队。团队不再是一盘散沙。

   9. 心情更舒畅。因为你相信PP时缺陷率会更低,并且有人与你同担风险。