估算是软件开发中还没有很好的解决的一个问题, 因此争论也很多, 水平也参差不齐. 我无法给出更好的估算技术, 只是想抛出几个问题和观点
 
1. 单一职责和问题优先让我们从几个常见的问题开始:
估实际工作量(人天)还是相对大小?如果两个类似的Story有一部分实现代码是可以彼此复用的, 那么它们的估算应该是一样的还是不一样的? 还是把复用的那部分拆出来单独估?修复Bug的工作量要不要估算? 要不要算进每个迭代的”速度”里?Team一起估还是找一个人来估?做了一段时间后, 要不要重估?这些问题通常会引起争论. 每种观点都有自己合理的一面, 这也是争论的前提之一. 但真正导致争论的, 是大家都忘了自己估算的目的, 忘了谁如何消费这个估算:
有时我们为了投标报价有时为了跟客户讨价还价有时为了team自己收集数据发现问题有时需要在两种实现方案之间做取舍…这么多目的, 怎么可能有一种方法满足所有的需求呢? 就算有, 那么这种通用的方法在某一个目的上也有可能不如专为这个目的而生的估算方法准确
我的观点是估算方法要与估算目的结合, 而估算本身要与目的分开:
单一职责原则: 一个数, 不要...阅读全文

2012-02-06
内聚的极限: 软件开发的不确定性原理高内聚是有极限的. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的. — 代码内聚设计的不确定性原理 
大家都知道量子力学的不确定性原理: 在微观世界里, 有几对物理量不能同时精确的测定, 包括速度与位置, 以及能量与时间. 比如当我们精确的测定一个粒子的速度使其误差很小的时候, 我们对其位置的测量误差从0到正无穷都有可能, 换句话说, 此时粒子可能位于宇宙的任何地方, 这里的极限就是二者误差的乘积总是大于一个被称为普朗克常数的数.
代码的设计有时会感到同样的张力: 无法做到完全的内聚. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的或耦合的. 无论是逻辑设计还是物理设计.
 
看一个代码逻辑设计的例子, 就是结构和行为.当代码在结构上内聚的时候, 在行为上是发散的. 主流的面向对象编程范式是按照结构优化的, 看一下你的代码中的class的名字, 大都是名词, 是一个事物, 表达了What the system is. 但这个系统具有什么样的行为, 能做什么事, What the syste...阅读全文

See also Lightening Talk: 简单设计
经常碰到的一段对话是：“这里为什么要引入一个类？字符串就好了，简单设计嘛” 或者 “一个switch/case就搞定的，弄个子类干嘛？”
事实通常是反过来的，引入新的类型或子类比使用字符串或switch/case更简单. 我来解释一下
设计是否简单的一个判断标准是它是否更容易理解. 而我们对事物的理解建立在概念或模型之上. 比如做一个最简单的超市存包系统，能存包能取包，没有进一步的需求. 牵扯到的概念可能有包裹，储物柜，存完包有个凭证用于取包. 这时我的设计中引入一个空类 public class Package {} 来代表包裹，另外一个空类 public class Ticket {} 来代表凭证. 你跟我说应该用字符串因为它更简单，反正也不会有新的需求, 我是不同意的. 我们来看采用这两种设计的代码，比如存包：
public Ticket Put(Package package){…}public string Put(string package) {…}用起来：
new Cabinet().Put(new...阅读全文

2012-04-08
专家系统的测试策略: 不可判定?—专家系统给测试和测试人员带来了不同的挑战.
我们日常接触到的软件大多为通用软件或者企业应用, 使用起来比较简单, 易于理解. 与之对应的,  有一类软件我们称之为专家系统, 它们协助某个领域的专家来做出判断和决策. 比如地质监测, 天气预报, 还有我们经常在电影里看到的科学家使用的各种模拟软件: 龙卷风灾难模拟, 变态教授的分子化学和新药品实验等.
直观的感觉, 这类软件已经与我们日常使用的软件不同. 具体一点, 我们从软件测试的角度来来理解一下专家系统带给我们的不同于通用软件的挑战:
使用者需要具备必需的专业知识, 而这个门槛通常不低.算法可能要求大量的输入, 数据不好准备算法的输入空间和结果空间太过巨大, 而且没有直观的对应关系. 即给定输入不能一眼就看出输出.一些类型的专家系统其界面展现是非常复杂的,远非普通的企业应用和个人软件可比.没有找到太多这方面的资料, 仅就以往经验和微博上的讨论做些总结.
1. 测试问题本质上是设计问题. 可测试性是很重要的设计约束. 表示逻辑和业务逻辑的分离，在复杂系统中更显必要...阅读全文

2012-02-27
On GUI Architecture: GUI应用的若干问题和模式我们所开发的应用程序大多都需要提供一个图形用户界面(GUI). 关于GUI应用的架构设计,
已经有了很多模式, 比如Martin Fowler的blog中有一篇"GUI
Architectures", 里面介绍了Form & Control, MVC, MVP, Passive View, Presentation
Model, Supervising Controller, Event Aggregator, Observer Synchronization等多种模式.
模式可以帮助我们建立优雅的架构, 但前提是弄清楚模式的应用场景. 这些模式自然不是凭空产生的, 都是为了解决具体的问题. 模式在实现上的差别,
通常都体现了在约束间的不同取舍, 以及问题的差别. 弄清楚GUI应用面临的设计上的问题, 有助于我们正确的挑选设计方案.
下面我们来看一些GUI应用常见的设计问题.
第一个问题就是界面的变化和业务的变化频率不同, 通常是界面变化更频繁,
而我们希望一方的变化不至...阅读全文