1，需求明确，却在实现的过程中遗忘。
上周五完成预计任务后，期望对整个代码进行优化。首先选择一个解析JSON的功能。最初的需求其中是2个：更轻松的使用 和 出现中小性质变动时不需要对代码进行修改。后者，相对而言比前者更加重要。
对于这个解析器设计，我零散的做过很多预想，中间也提取过各类需求。但，在整理需求时，我出现了一个错误：设计类就遗忘了需求。像我上面所说的，我的期望是使用和未来的少变动。但实际上，我在设计的最初，也是依据这2个目标去完成的，设计了一个类似下面的类
class A{
public:
virtual usingA();
virtual GetValue();
};
看起来应该是正确的，结果呢？。。。竟然发现无法直接用于已有代码中。
很坑爹？是的，我用了接近一个小时去提取需求，整理规划。然而，在真正设计时，我竟然忘记了需求。当然，如果从设计角度，这个做法本身并没有错误，因为这个类的设计方式，更加符合一般性规则。然而，我的使用前提，应该是在不变更当前已有代码的基础上完成类的修订。
大概有人会说，既然你觉得现有的更好，应该让修正已有代码啊。然而，事实上，如果我重新优化现有代码，需要的时间可能是一周，在工作上，这可能是完全不允许的。
所以，我大概浪费了2个小时时间，做了2小时以后就删除了的类框架。
2，在实现之前，应该使用类对象模拟使用。
上述例子中有一个幸运在于，这个类的实现使用了大部分已有的代码和工具类，所以实现的过程大略半小时就完成了一半。此时，在测试时，才发现原来设计的东西无法使用。《代码大全》中描述，越早发现问题，修复的成本越低。
实际上，我正在尝试一种编码习惯：设计完类后，先将其放入适用场景去使用，看是否能够符合要求。
这个规范其实可以更延伸一些：当实现一个复杂功能函数时，直接在其中使用未完成子程序（甚至未声明和设计）。这样的好处有：
1，代码看起来更清晰。
2，复杂功能的函数代码不会过长。
一个简单的例子：
放大象到冰箱(){
打开冰箱（手）;
放入物品到冰箱（手，大象）;
关闭冰箱（手）;
}
这种方式有一个好处：在你没有非常清晰的函数需求，参数需求时。你可以通过编程中渐渐清晰。例如此例，你最少知道需要这样3个函数，和2个形参（或成员变量）。
但，这种方式从本质上，并不适合用来设计类，因为它是从指向性需求来规划类的。而类的设计应该是抽象的概念。
可是，在你根本没法再指定时间内（工作是有时限的）完全的设计出类时，可以参考此方法。