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时缺陷率会更低,并且有人与你同担风险。