Blog

Blog

PHODAL

知识论(一): 知识传递

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

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

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

知识传递

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

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

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

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

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

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

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

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

代码

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

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

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

团队

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


  1. http://www.infoq.com/cn/news/2009/08/agile-knowledge-transfer 

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签