UKoom

Don't Repeat Yourself (DRY, also known as Single Point of Truth) is a process philosophy aimed at reducing duplication, particularly in computing. The philosophy emphasizes that information should not be duplicated, ...

对于一些框架软件，例如springframework来说，要测试的是API实现的逻辑，这种情况下大量mock隔离其他对象的影响是必要的。但是对于我们应用程序，特别是数据处理型应用，你不测试数据库访问，根本就等于没有做测试。换句话说测试DAO就是在测试你的Hibernate映射关系有没有配对，你的HQL查询有没有写对，这一Mock，要测试的真正目标根本就没有达到。   这种DAO测试诚然就是集成单元测试，其实就是对于Web Action测试，我也曾经一度认为应该mock service来测试，但是现在我已经不这样做了，而是真正初始化webwork的容器注入真正的service对象来测试了。因为...

When I write code, elegance is something I aspire to, and in some senses goes hand-in-hand with beautiful code, but that doesn't really make it any clearer. Certainly, I think there is a strong element of "elegance is ...

Single sign on is a session/user authentication process that allows a user to provide his or her credentials once in order to access multiple applications. The single sign on authenticates the user to access all the applications he or she has been authorized to access. It eliminates future authenticaton requests ...

今天在网上看到了一篇文章，是关于华为实施敏捷项目管理经历的。 在这 http://www.javaeye.com/topic/313741 很有感受，基本上把我所知道的敏捷理念还有一些开发流程，管理流程整理了一遍。再加上最近一直在看和推敲的GSK公司的iQMS，结合这篇文章，将心得略写于此。 IPD我想就是一个check list。然后其配合CMM来控制质量。质量是保证了，但速度同样重要，这时就需都要尝试心得实践方法。XP应运而上，这些实践的出发点是同时保证质量与速度，但其缺点也很明显，可操作性不是很强。不易于管理。这时SCRUM来了，结合SCRUM和敏捷实践。降低风险，保质，保速。同时还有RUP，RUP需要深入的东西很多，同时其对工具的依赖性较大（虽然这点我没有体验），但我感觉RUP的复杂性是一方面，同时IBM的专属性，面向的客户的狭隘也限制了其推广。 前年初我接触到了SCRUM，深研了一番。呵呵，非常棒的东东。 这篇文章里的几句话很有总结性： 1. scrum很简单，三个三 2. 软件开发中有三个要素： 人，过程，技术和工具。 三者都不可省。各种开发方法在操作时偏重点不同。 同时作者也列出了一些经验。 我只是没想到华为也开始引入了敏捷，原来一直以为作为国有企业（国有？）的华为会比较“死板”和“正规”，但是又想一想微软在项目中也引入了Scrum，于是，哦。。。 呵呵

异地分布式敏捷软件开发 (Distributed Agile Software Development) 异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。 异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。 但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位 置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离 岸，通常在时差8小时以上）。如下表。 offsite on shore near shore off shore Distributed Development 北京办公室 - 西安办公室之间 印度分公司 - 中国分公司 硅谷总公司 - 中国或印度分公司 Outsourcing Development 北京某公司 – 广州另一公司 东京某公司 - 大连另一公司 欧洲某公司 - 中国另一公司 异地分布式开发的组织方式 异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。 有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。 各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。 基本原则：极尽交流之能事 异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。 为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。...

1. Every fixed defect on a deployed product has tests added to prevent regression. The worst thing you can do in this business is to have the same problem twice. Prevent it - our clients and users will usually ...