犯錯記錄(一）

　　1，需求明確，卻在實現的過程當中遺忘。

　　上週五完成預計任務後，指望對整個代碼進行優化。首先選擇一個解析JSON的功能。最初的需求其中是2個：更輕鬆的使用 和 出現中小性質變更時不須要對代碼進行修改。後者，相對而言比前者更加劇要。

　　對於這個解析器設計，我零散的作過不少預想，中間也提取過各種需求。但，在整理需求時，我出現了一個錯誤：設計類就遺忘了需求。像我上面所說的，個人指望是使用和將來的少變更。但實際上，我在設計的最初，也是依據這2個目標去完成的，設計了一個相似下面的類

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

　　看起來應該是正確的，結果呢？。。。居然發現沒法直接用於已有代碼中。

　　很坑爹？是的，我用了接近一個小時去提取需求，整理規劃。然而，在真正設計時，我居然忘記了需求。固然，若是從設計角度，這個作法自己並無錯誤，由於這個類的設計方式，更加符合通常性規則。然而，個人使用前提，應該是在不變動當前已有代碼的基礎上完成類的修訂。

　　大概有人會說，既然你以爲現有的更好，應該讓修正已有代碼啊。然而，事實上，若是我從新優化現有代碼，須要的時間多是一週，在工做上，這多是徹底不容許的。

　　因此，我大概浪費了2個小時時間，作了2小時之後就刪除了的類框架。

　　2，在實現以前，應該使用類對象模擬使用。

　　上述例子中有一個幸運在於，這個類的實現使用了大部分已有的代碼和工具類，因此實現的過程大略半小時就完成了一半。此時，在測試時，才發現原來設計的東西沒法使用。《代碼大全》中描述，越早發現問題，修復的成本越低。

　　實際上，我正在嘗試一種編碼習慣：設計完類後，先將其放入適用場景去使用，看是否可以符合要求。

　　這個規範其實能夠更延伸一些：當實現一個複雜功能函數時，直接在其中使用未完成子程序（甚至未聲明和設計）。這樣的好處有：

　　　　1，代碼看起來更清晰。

　　　　2，複雜功能的函數代碼不會過長。

　　一個簡單的例子：

放大象到冰箱(){
    打開冰箱（手）;
    放入物品到冰箱（手，大象）;
    關閉冰箱（手）;
}

　　這種方式有一個好處：在你沒有很是清晰的函數需求，參數需求時。你能夠經過編程中漸漸清晰。例如此例，你最少知道須要這樣3個函數，和2個形參（或成員變量）。

　　但，這種方式從本質上，並不適合用來設計類，由於它是從指向性需求來規劃類的。而類的設計應該是抽象的概念。

　　但是，在你根本無法再指定時間內（工做是有時限的）徹底的設計出類時，能夠參考此方法。