August 23 23:28~24:00；August 24 00:~00:28
▲貼上封印的實務做法將使電腦無法洩露資料… （黑人問號？？？）
施展不開的苦惱
Teddy有一個很認真學習的朋友，有機會就到外面上課進修。最近這位朋友告訴Teddy他在學習上的一個困擾…
朋友：我上了很多課程，尤其是實戰班，我都有好好的練習。只要我回公司之後，在工作上遇到的問題跟上課時所教的問題一樣，我就能夠處理。但是，只要稍微有點不同，我就不知道要怎麼處理。
聽完朋友的敘述，Teddy的第一個反應就是—「你只是照著人家教你的特定招式練習，你根本沒有真的學會啊。」這種學習模式，只要情境稍微改變，原本罐頭式的解決方案很可能就派不上用場了，而你又不知該如何調整原本的罐頭，讓它在新的情境中派上用場。
***
理論和實務
理論和實務，經常被視為學習天平上的兩端。理論給人的感覺就是抽象、嘴砲、和社會脫節、無法實戰等。實務給人的感覺就是具體、立即可上手，就好像武俠小說中吃了天山雪蓮一樣，立刻增加一甲子的功力。
實務就好像例子（example or instance），非常具體、容易理解且容易照做。如果實務所描敘的情境（context），與問題（problem）和你工作上所遭遇的相同，便可立即套用。但通常越具體、越實戰的實務，其適用的情境也越特定（越窄）。所以，同一種「類型」的問題，可能衍生出數種甚至數十、數百種例子。如果沒有理論基礎的支援，沒有建立分析問題的框架或模型，需要靠自己慢慢地累積各種實戰經驗，然後再抽象化成為自己腦中的解題模型。這是一個冗長的過程，很多人還沒走完這個過程就放棄了，永遠都在「學例子」，而沒有學到例子背後的共通理論基礎。
***
建立收納知識框架
這幾天在某本書（這幾天看的書比較多，忘了哪一本。應該是溫柏格的某本書中引用另外一個人的話，要再找一下）讀到一句類似的話：
好的理論就是最好的實踐，因為它放諸四海皆準。
真是太有道理了。如果你的學習過程，發現自己都在忙碌的收集流行術語，以及參加各種經驗分享，搞到最後自己越學愈心慌。此時就應該停下來思考一下，你有看到人家背後的理論基礎、框架或模型嗎？
舉個Teddy自身的例子，Teddy博士論文的題目是「Java例外處理設計與重構」。一開始Teddy並不是研究這個題目，而是先研究pattern language，幾年後改研究design by contract裡面的contract specification。design by contract其實包含了contract specification與exception handling，但當時Teddy覺得exception handling太難，雖然有很多程式範例與所謂的best practices，但就是缺少一個理論框架，所以這一大堆例子與best practices在實際應用的時候經常互相衝突或不足夠完整解決問題。柿子挑軟的吃，所以Teddy一開始只研究contract specification。
後來陰錯陽差，花了許多時間研究exception handling，也建立了一個理論框架（很簡單的理論XD）來解釋例外處理設計的問題。有了這個框架，分析與設計應用系統的例外處理就變得很有系統化。
***
要怎麼從別人的教學中建立知識框架？最重要，也是最簡單的一點，就試看看教學者有沒有給你源頭參考資料。有些人強調自己的內容就是「原創」，但事實上這個世界真的「原創」的知識非常少，絕大部分都是建立在前人的知識體系上增加價值。好的實例，應該要建立在某些理論基礎之上。上課時可以不談這些理論基礎，但必須要提供參考資料，讓學習者課後有機會可以藉由進一步學習理論基礎來建立收納知識的框架以及培養自我解決問題的能力。
小心「斷水流式」的第二手 （第或N手）知識傳遞，無法追源溯流的知識只能在非常特定的情況下使用，跟「呼名大法」（請參考〈自我感覺良好神功（１）：呼名大法〉）相去不遠矣。
***
友藏內心獨白：巨人知道你站在他的肩膀上嗎？
