犯错记录(一）

　　1，需求明确，却在实现的过程当中遗忘。

　　上周五完成预计任务后，指望对整个代码进行优化。首先选择一个解析JSON的功能。最初的需求其中是2个：更轻松的使用 和 出现中小性质变更时不须要对代码进行修改。后者，相对而言比前者更加剧要。

　　对于这个解析器设计，我零散的作过不少预想，中间也提取过各种需求。但，在整理需求时，我出现了一个错误：设计类就遗忘了需求。像我上面所说的，个人指望是使用和将来的少变更。但实际上，我在设计的最初，也是依据这2个目标去完成的，设计了一个相似下面的类

class A{
    public:
        virtual usingA();
        virtual GetValue();
};

　　看起来应该是正确的，结果呢？。。。居然发现没法直接用于已有代码中。

　　很坑爹？是的，我用了接近一个小时去提取需求，整理规划。然而，在真正设计时，我居然忘记了需求。固然，若是从设计角度，这个作法自己并无错误，由于这个类的设计方式，更加符合通常性规则。然而，个人使用前提，应该是在不变动当前已有代码的基础上完成类的修订。

　　大概有人会说，既然你以为现有的更好，应该让修正已有代码啊。然而，事实上，若是我从新优化现有代码，须要的时间多是一周，在工做上，这多是彻底不容许的。

　　因此，我大概浪费了2个小时时间，作了2小时之后就删除了的类框架。

　　2，在实现以前，应该使用类对象模拟使用。

　　上述例子中有一个幸运在于，这个类的实现使用了大部分已有的代码和工具类，因此实现的过程大略半小时就完成了一半。此时，在测试时，才发现原来设计的东西没法使用。《代码大全》中描述，越早发现问题，修复的成本越低。

　　实际上，我正在尝试一种编码习惯：设计完类后，先将其放入适用场景去使用，看是否可以符合要求。

　　这个规范其实能够更延伸一些：当实现一个复杂功能函数时，直接在其中使用未完成子程序（甚至未声明和设计）。这样的好处有：

　　　　1，代码看起来更清晰。

　　　　2，复杂功能的函数代码不会过长。

　　一个简单的例子：

放大象到冰箱(){
    打开冰箱（手）;
    放入物品到冰箱（手，大象）;
    关闭冰箱（手）;
}

　　这种方式有一个好处：在你没有很是清晰的函数需求，参数需求时。你能够经过编程中渐渐清晰。例如此例，你最少知道须要这样3个函数，和2个形参（或成员变量）。

　　但，这种方式从本质上，并不适合用来设计类，由于它是从指向性需求来规划类的。而类的设计应该是抽象的概念。

　　但是，在你根本无法再指定时间内（工做是有时限的）彻底的设计出类时，能够参考此方法。