良好程式碼的優點大同小異。
不好的程式碼的糙點卻各有巧妙之處。

開發體驗!!是本篇要講的重點。

在此引用大師 Donald A. Norman《The Psychopathology of Everyday Thing》(中譯: 《設計的心理學》翻譯品質很好哦)用來分析設計的框架，試著用來分析程式設計看看

優良設計的兩個重要特點

1. understanding 易理解性
2. discoverability 可發現性

如果是複雜的設備，就要用手冊或指南。簡單的設備不用。

為何借助設計的心理學

書中含蓋包含複雜與簡單的設計。程式開發的對象，往往是複雜的設備，試著以這本書的方式來看看程式碼在這個面相有什麼有趣的觀點吧。

書中主張 Human-center design，重視人類需求、能力、行為用設計滿足這些條件。
這篇試著主張 Developer-center design，重視開發者需求、能力、行為用設計滿足這些條件。(哈哈~~ )，不過這一類的設計書，簡單的假設都是「使用者是笨蛋」，想對程式品質講究的小弟我，應該也是腦容量小、記憶力不好，但是又試圖的可以處理一整個系統性的專案，這樣的技巧確實可以放大處理專案的大小。

書中提出了幾個 Human-center design 的原則

1. 避免過早定義問題
2. 利用重複漸進的方式來趨近問題
3. 快速的測試設計的想法
4. 每次測試後修改設計方式和問題的定義

結果上，會是真正滿足人們需求的產品。
在嚴格規定的 時間、成本、資源 這將會是一種挑戰。

其實以軟體開發而言，這不就是敏捷精神？快速迭代、建立回饋、即時修正方向....

當我們與產品互動，需要弄清楚如何使用它。
包括發現它能做什麼事以及該如何操作: 稱為「可發現性」
它包括五個基本的心理觀念，再加一個對系統的「概念模型」

• discoverability 可發現性
  1. affordances 預設用途
  2. signifiers 指意
  3. constraints 使用局限
  4. mapping 對應
  5. feedback 回饋
  6. conceptual model 概念模型

第 6. 點，呼應了《沒有銀彈》中提到的「整體概念性」的重要。

繼續上篇，接著介紹

使用局限

局限是一種不允許的指意。

利用語言細節的特性，強迫使用者不犯錯的美妙設計。
容錯性高的 JavaScript 就比較少這種強迫的限制了。

在 C++ 就很多限制的設計，其中有一個「純虛擬類別」，可以視為 Java 的「Interface」，它沒有自己的實作，但是繼承它的，就必須擁有這個 interface 的實作。

class Sharp {
protected:
  virtual void Draw() const = 0;
}

class Circle : public Sharp { // Circle 繼承 Sharp = Circle is a Sharp
public:
  // 一定要實作 Draw 
}

這種限制，還變成了一個 Design Pattern[1] 的特性

class Creator{
    //...
protected:
    virtual Product *DoCreateProduct(void)=0;
};

class CreatorA: public Creator{
public:
    inline Product *DoCreateProduct(void) override {
        return new ProductA;
    }
};

class CreatorB: public Creator{
public:
    inline Product *DoCreateProduct(void) override {
        return new ProductB;
    }
};

在 Python 中，就強迫使用者一定要有優美的縮排。
而且不可以混用縮排符號，讓寫 Python 的人一開始就養成寫好 code 的習慣。

回饋

必須即時回應

這個概念在控制理論和資訊理論中較常見。

回饋多 → 煩人
回饋少 → 不知所云
回饋不適當 → 不知所云

這是個最美好的時代，同時可以享有過去開發者的成果，也可以享有過去開發者的辛苦。
怎麼說呢？

早期的程式語言在送進編譯器處理之前，必須要先經過流程圖、撰寫表格、打卡，

早期: 無即時回饋

以前寫程式，沒有使用個人電腦，沒有友善的開發環境，不會即時告訴你是不是出錯了。
想知道程式是否正確執行，要將卡片交給祭司計算機中心的人員，再幾週之後，會得到神諭執行結果。

缺點: 不即時!!現在沒有人這樣做了

現代: IDE 提供即時回饋

現在的 IDE 除了即時給予編譯錯誤，還會在編譯之前就畫紅線提醒你語法出錯。開發環境的美好，除了報錯，還提供 autocomplete 自動補滿你想寫的程式碼。但是，功能愈強大，效能就吃愈多。這也是很直接的回饋。

網頁前端開發者，使用複雜的前端框架，往要配合瀏覽器的 dev-tool 回饋除錯訊息。不再單純的只是由 debugger 一行一行的追縱，因為會追到前端框架本身的程式碼，對開發者來說，不一定是熟悉的。

這是美好之處，總是找得到給予回饋的工具。

觸到了師父從未指點過的境地[2]

而這個時代的，不美好之處在於，也許冷門的瀏覽器往往是客戶希望或者剛好可以重現問題的環境，但是它卻沒有相對應的 dev-tool 可以使用。就只能用猜的。體會過去開發前輩們的辛苦。

但是，除了 debugger ，在開發時，最常見的就是自己印出訊息，這就是「自己要的回饋自己印」呀。

hello world

這也是為什麼每本語言書的第一個程式，都要教你 hello world ，除了致敬 K&R 之外，實質上的用途就是在學習 debugger 前的初學者也可以獲得 debug 的回饋訊息。

概念模型

概念模刊的價值，在於提供一個預測事情會如何進行的理解方式，以及事情不按計畫進行時，能提供排除障礙的方法

開發心智模式 ≠ 使用者心智模式

開發心智模式經典的例子，就是 Design Pattern 的 23 個 Pattern 解決開發時的各種問題。使用者在使用軟體或網站時，完全不需要知道工廠模式、建造者模式、觀察者模式....
使用者只需要知道自己專注的問題，以及該問題的領域知識，就可以解決自己的問題。

在此的概念模型，指的是開發者的心智模式，無關使用者 (客戶或業主)。
開發者體驗要好，就是要用一致的設計語彙，而這樣的語彙往往被稱為內功心法。其實最簡單的實踐原則就是詳讀各個套件、框架的文件，提供給心智模式，適切的使用譬諭在程式碼的字裡行間，讓閱讀程式碼可以沒有太多的小聰明就可以了解大部份的運作模式了。有完好的概念模型，使開發者快速學習與快速上手。減少開發時程與 bug 產出率。

像是後端框架，總是給你 MVC 架構的概念。告訴你什麼邏輯該寫在哪。

快速學習的祕訣，在於適當的比諭，適當的將一個陌生的事物，套上一個熟悉的概念，然後透過這個概念再慢慢的調整成適切的認知，可以快速的。

參考資料

[1]: Builder Pattern - wiki
[2]: 《臥虎藏龍》談覺知心 相應的行苦