本文重點

1. Framework Design Guideline 這本書到底再寫什麼內容？
2. Framework Design Guideline 看完後預計會有什麼收獲？
3. Well-Designed Framework

這本書到底再寫什麼內容？

話說為什麼會選這本書是因為推薦

但是這本書到底再寫些什麼內容，總不能30天後全部看完才知道吧

又不是推理小說來著的

就讓小的我來稍微簡介一下這本厚厚的原文書吧

30天後如果有人要二手購入的，歡迎內洽喔～

（到底要去哪裡內洽？？？？？）

Guideline - 指導方針

顯然是.NET的一本教科書來著，內容包括

1. 程式命名規則
2. 各種Type的設計
3. 什麼情況應該使用哪個Type
   Type就是包括Class，Interface，Emun那些我們會新增檔案的程式
   什麼時候要用Class，什麼時候要用Struct
   每個Type的說明與之間的差別
4. Type裡的Member又該如何設計
   Member就是Type中的成員，包括property，Method...這些，you know
5. Exceptions的設計方式
6. 還有一些常用的元件要注意的地方

咦？這不是把第一天的東西又打了一次XD

看完後預計會有什麼收獲？

只要照著書中的Guidelines

就可以創造出一個前無古人後無來者驚天動地無所不能的Framework

是不可能的！！！

但是可以創造出一個設計良好容易閱讀方便擴充人見人愛的Framework

話說我連Framework都沒寫過

未來也沒有計畫開發

讀這個真的對目前的我有收穫嗎？

不用擔心，就算沒有那種天分寫出好的Framework造福大眾

我對自己的期許，希望讀完本書後至少能將下列應用到未來的工作上

1. 建立自己的Coding standard，發現自己以往的錯誤
   像是不要用組織名稱來作為Namespace
2. 常用元件在使用上的愚蠢錯誤
   像是不要宣告一個readonly的Array
3. Type跟Member的選用取捨
4. Exceptions的使用方式跟時機
5. 增加英文閱讀能力

Well-Designed Framework

Framework是我們每天都在使用的東西

好的Framework帶你上天堂，不好的Framework帶你住套房

相信大家都有過一邊Coding一邊幹譙的情況吧

『這甚麼鬼!!這麼難用!!』

『到底這個Method在寫些甚麼?』

『甚麼爛東西?為什麼沒有提供blablabla...功能』

"好" 這件事情其實很主觀的

『可以用來解決問題的就是好東西』

『沒有Bug就是好程式』

『需要全方面考量設計的完美計畫才能叫好』

每個人對於"好程式" "好設計" 的定義都不盡相同

一般而言，想開發一個品質良好的Framework，至少得考量下列幾點

• 簡單
• 需要一直權衡取捨
• 不要標新立異
• 擴充性
• 完整性
• 一致性
• 經得起考驗
• 昂貴

接著就讓我們來各個擊破吧!!

簡單

『簡單好用』應該所有工程師在使用別人的套件時最希望遇到的事

很多厲害的傢伙常會迷思在我寫的東西多強大多完美

但寫出來的東西只有自己知道怎麼使用

這種慘品怎麼賣得出去

把功能簡化，按照各種情況獨立開發，不要一個大坨的

如果有更複雜的設計或邏輯，下一個版本再說吧

如何判斷這是個『簡單』的設計

使用『client-first programming』來測試自己的功能是否方便使用

這裡所謂的client指的就是我們工程師

也就是framework使用者，畢竟framework是開發給工程師用的

決定功能內容與input/output之後

找幾個工程師來問問

『如果有一個blablabla功能

你希望如何使用?

輸入甚麼?

回傳甚麼?』

如果大部分的人回答的內容跟你原先設計的不一樣

那就表示這個設計並不符合client的需求，再調整吧

需要一直權衡取捨

所以Framework需要甚麼功能，不要甚麼功能

要怎麼定義?怎麼實作?

都是需要Trade-Offs

要不斷經過討論調整

不要想要一個人躲起來想東想西的

出來聽聽聽大家的意見吧阿宅

不要標新立異

不要想要用甚麼創新的技術

盡量使用已經經過時間的淬鍊與多人的測試傳承下來的Design Pettern

百年老店，品質保證

不要隨便加入一個新的觀點

那會讓你的Framework增加失敗的機率

擴充性

這是為了『以防萬一』

雖然強調擴充性，但是為了不讓擴充功能搞壞了整個設計

記得把新的東西加在下一個版本

不要在目前版本放做了一半的半成品

畢竟『需要一直權衡取捨』(Trade-Offs)經過設計與討論之後才有變成產品的價值

完整性

這點我覺得有點太龐大

意思是指一個好的Framework必須能夠符合整個開發大環境

包括可以應用在不同的工具、程式語言與應用程式

目前為止有人做到全部嗎?

一致性

風格一致是一件很基本很重要卻好像很難做到的事

大家都討厭客戶變來變去的吧

但是其實我們也很常在變來變去

命名風格、設計風格、程式風格一致性

可以讓使用者更快速了解並上手

還記得上面說的『不要標新立異』嗎?

就讓你的Framework像iphone一樣，簡約、舒服

經得起考驗

除了Unit Test之外

還要把自己當作使用者來使用Framework

不是做完Unit Test就能宣稱是個tastable的Framework

站在使用者的立場面對自己開發的難用Framework吧

這時請擺脫『自己的小孩總是最可愛』的盲點

價值不斐

這一點應該是跟老闆說的

看完上面的論點之後

應該可以體會到一個好的Framework是需要大量的時間跟人力的

畢竟一分錢一分貨一枝草一點露

一個Alan一個月一個Framework

只想跟主管講

後繼

已無力...

昨晚看到半夜一點半導致失眠...

30天會不會撐不下去咱們明天見