[Defect Identification] 两件事先后发生，不代表两者有因果关系
两件事先后发生，不代表两者有因果关系。 这简直是废话，但在处理古怪缺陷时我们常常会忘记这一点： 一拉电灯线房子就倒了，我们很容易就以为是房子是被拉倒的；于是百般分析电灯线和房子之间的力学关系，直到多年后有个人在外国出了一本回忆录，回忆录上说他当年是怎么挖地道偷渡的。
Month: October 2010
[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时缺陷率会更低，并且有人与你同担风险。