知識論(一): 知識傳遞

做近一在一些和知識傳遞(knowledge transfer)相關的事，只是這種是因為是每個人一直都在做的事，不同的是要從一個接收者變成一個傳送者。在重新看了看《認識設計》一書，加之之前的Coaching培訓，算是在這方面有了點小小的經驗。

不幸的是，在有了這些瞭解之後，在這周裡有幸Review了Manning出版社的一本關於物聯網的草稿的目錄，作者是一個PhD，看裡面的內容很有深度。然而目錄看上去不讓人滿意，學習曲線陡得有點異常，又少了點實踐。這不像是給看些搞IT的人玩的書，更像是寫給資深的人看的，但是資深的人又不需要這樣的書了。對於知識傳遞這一事來說，不像是一個好的目錄。

於是，就重新思考了一下，知識傳遞到底應該是怎樣的?

知識傳遞

將某種情形下的知識從一個單位（可以是個人、團隊、部門、組織）傳遞到另一個單位，這就是知識傳遞。^knowledge

對於傳統軟體開發團隊來說，知識會存在於三個地方:

1. 文件
2. 少數人
3. 程式碼

對於敏捷軟體開發團隊來說，知識會存在於三個地方:

1. 團隊
2. 測試
3. 程式碼

合併一下上面知識，我們可以將其歸併為人與文件。傳統軟體開發與敏捷軟體開發的很大的不同在於——知識的傳遞方式:

1. 傳統軟體開發流程中，知識傳遞的方式主要在於文件，而我相信在網上已經有足夠的證據可以表明，程式設計師既討厭看文件，又討厭寫文件。

2. 敏捷軟體開發流程中，知識儲存的地方在於團隊中的人以及程式碼中。一個好的測試用例會覆蓋到軟體的一個功能，那麼相應地如果軟體的功能都到測試到了，那麼我們就知道軟體的所有功能。敏捷開發流程的兩個優勢在於結對程式設計與Code Review，這樣會讓團隊中的所有人都具有同等的知識。

程式碼

如果你不知道一坨程式碼的功能、沒有文件、沒有測試，也沒有人知道它的功能，那麼我想這程式碼是完了。這也說明了在這個專案中，知識的傳遞是有問題的，接著這個專案就變成了遺留專案，在這樣的專案中程式設計是極大的挑戰。

故而程式碼整潔的實質便是更好的達到知識傳遞的目的，那些傳遞不了知識的程式碼就是那些魔法數字、過長的函式、過大的類等等。有意思的是如果團隊成員整體水平不高，那麼設計模式也是一種傳遞不了知識的程式碼。畢竟，不在同一個水平上的程式設計師很難相互之間交流。

還有一個便是測試用例，好的測試用例會告訴我們該往何處走。

團隊

團隊在某種程度上是知識的擁有者，在團隊中傳遞知識的最好方式便是結對程式設計。在結對程式設計的過程中，我們可以對新人進行指導。無疑這樣的成長方式是最快的，我們直接將所有的知識傳遞給另外一個人。除此之外，還有我們工作的方式。

ps: 最近比較忙 + 比較熱，靜不下心好好寫。