HOW ？™

流程：
1. 業主會談，了解需求。
建立案例，透過會談將需求與系統運作能有非正式的描述，讓業主與工程師能瞭解要做什麼，寫明細節、認清問題大小與範圍。
在這邊有一段模擬的對話，中間瞭解我為何在工作時會遇到的瓶頸，主要的原因在於拿到規劃書就埋頭苦做，實作當中會遇到許多細節的部分，這時候就會卡住，甚至獲得細節答案後，會導致系統要重寫，而此時又不願意重寫，就開始破壞原先的邏輯，強制導正為新的邏輯，增加許多未來維護的困難，降低可讀性。

以下我用5W2H的方式來作筆記，有些地方或許不太合理，但可以加強我的記憶。

WHO：系統使用者為誰。
HOW：系統流程，案例的流程建議將系統運作無關的行為應該要排除在流程之外(簡化流程，不必要的細節可以省略)，另外，技術層次的字眼盡量不要出現，如，系統GET QueryString獲得ID，使用此ID來對資料庫的資料表Customer...，實作案例前，將案例以抽象、比較沒有技術層面的說明，避免寫實作的細節，甚至這邊不應該提到，ID的獲取方式。
WHAT：需求的目的，在於查驗使用者想要的，並確認實作後系統是否吻合這些需求，主要的特性規格為，可靠性、可測試性、可部署性和效能佳，是否要將特性諸於文件則觀看系統的大小與複雜度。
WHERE：避免重複發明，哪邊是否已經有所需功能的之工具或現存的程式，創建新解法解決問題前，先找既有的解法。
WHY：專屬的名詞，每一種物件都有許多種稱呼，而每種稱呼或許有不同的定義存在，為了避免誤解，最好問清楚，此名詞在這邊的定義與作用，說不定會發現更多的細節，系統中每個概念都要定義清晰的名詞，最好能與客戶使用的相同。

結合兩個概念，比起分離一個概念簡單許多。
這邊提到的是如果能切割成不同的類別，就應該切割出去，但有一天發現，有兩個類別沒什麼差別，此時利用取代，而如果一開始就只有一個類別，日後要區分時，就必須先將該類別重頭言就到尾，才能確定是否該歸屬為另一個類別。
這個觀念讓我有點錯愕，大多時候我都是直覺化的將程式寫完，才開始重構將不同的職責拉出不同的類別，書中的說法，與我的寫法觀念相反。

 

把資料凝結成塊可以減少必須駐留心中的概念數量。
許多屬性為共通為一個名詞的概念，則可將這些屬性凝結成一個類別。

凝結成塊：一組屬性結合到單一已命名的概念下。
混合成塊：單一名詞有兩種不同的概念，而兩種不同的概念差異不大，則可合併為一。

有關本章節最後抽象化，讓我有一點不太能接受，如果連Count都寫一個類別，那...開發的時程不就很驚人！

經由Allen講解後，才瞭解有這個必要性，以地址為例，有不同種的格式的輸出，透過抽象化，只需要撰寫一次code，可免除未來要重寫驗證、組合...等。

2.開發人員，調整開發環境與方法
 

 

 

如文章有錯誤，煩請告知，新人發帖請多包涵