做近一在一些和知识传递(knowledge transfer)相关的事，只是这种是因为是每个人一直都在做的事，不同的是要从一个接收者变成一个发送者。在重新看了看《认识设计》一书，加之之前的Coaching培训，算是在这方面有了点小小的经验。

不幸的是，在有了这些了解之后，在这周里有幸Review了Manning出版社的一本关于物联网的草稿的目录，作者是一个PhD，看里面的内容很有深度。然而目录看上去不让人满意，学习曲线陡得有点异常，又少了点实践。这不像是给看些搞IT的人玩的书，更像是写给资深的人看的，但是资深的人又不需要这样的书了。对于知识传递这一事来说，不像是一个好的目录。

于是，就重新思考了一下，知识传递到底应该是怎样的?

知识传递

将某种情形下的知识从一个单位（可以是个人、团队、部门、组织）传递到另一个单位，这就是知识传递。¹

对于传统软件开发团队来说，知识会存在于三个地方:

1. 文档
2. 少数人
3. 代码

对于敏捷软件开发团队来说，知识会存在于三个地方:

1. 团队
2. 测试
3. 代码

合并一下上面知识，我们可以将其归并为人与文档。传统软件开发与敏捷软件开发的很大的不同在于——知识的传递方式:

1. 传统软件开发流程中，知识传递的方式主要在于文档，而我相信在网上已经有足够的证据可以表明，程序员既讨厌看文档，又讨厌写文档。

2. 敏捷软件开发流程中，知识存储的地方在于团队中的人以及代码中。一个好的测试用例会覆盖到软件的一个功能，那么相应地如果软件的功能都到测试到了，那么我们就知道软件的所有功能。敏捷开发流程的两个优势在于结对编程与Code Review，这样会让团队中的所有人都具有同等的知识。

代码

如果你不知道一坨代码的功能、没有文档、没有测试，也没有人知道它的功能，那么我想这代码是完了。这也说明了在这个项目中，知识的传递是有问题的，接着这个项目就变成了遗留项目，在这样的项目中编程是极大的挑战。

故而代码整洁的实质便是更好的达到知识传递的目的，那些传递不了知识的代码就是那些魔法数字、过长的函数、过大的类等等。有意思的是如果团队成员整体水平不高，那么设计模式也是一种传递不了知识的代码。毕竟，不在同一个水平上的程序员很难相互之间交流。

还有一个便是测试用例，好的测试用例会告诉我们该往何处走。

团队

团队在某种程度上是知识的拥有者，在团队中传递知识的最好方式便是结对编程。在结对编程的过程中，我们可以对新人进行指导。无疑这样的成长方式是最快的，我们直接将所有的知识传递给另外一个人。除此之外，还有我们工作的方式。