反思软件开发：知识流动（中）

在上篇文章，即《反思软件开发：知识流动（上）》中，我激情昂扬地陈述了日常工作中常会遇到的比较恼人的几个问题，并从常规视角简单说明了问题所在，本文将会从知识的角度指出它们产生的原因为何。

基本原理

在分析并解决问题之前所必须了解的一些事情。

知识定义

在《客观的现实世界》中讲「DIKW」（即「data」、「information」、「knowledge」和「wisdom」）时，我简单地解释了「知识」是什么——

通过「数据」和「信息」只能了解到「实体」的表面呈现，这些是不可靠的，对人的活动基本没有指导意义，人们需要的是能够尽可能正确地反映「实体」的「性质」与「逻辑」的「知识」。

「知识」可以通过建模的方式获取，即将「信息」分门别类后抽取相同特征并简化为「模型」。「知识」不一定是真的，人永远也无法确切地知道其到底是不是真的，只能通过不断的验证使其无限接近于真。

欧雷《客观的现实世界》

为了方便阐述和理解，本文将默认不严格区分「数据」、「信息」与「知识」这几个概念，可以临时把它们看作是一回事——都是「知识」。

这样一来，在本文的语境中，职业、专业、业务等领域知识是「知识」，语言、文字、图形、代码等符号系统也是「知识」。

将「知识」根据是否被符号系统外化分类的话，已外化显现并记录下来的叫它「显性知识」，未经外化仍存在于某个人的意识中的称为「隐性知识」。

基于「万物皆可描述」的理念，任何「隐性知识」都可被适当的形式描述出来，即便会有一定程度的失真，这就是「隐性知识显性化」——同时也是让知识流动起来的基本前提。

知识封装

简单来说，「封装」就是用一个符号去压缩或者说包装一些有所关联的知识，就像打包好的快递包裹一样。这样做的目的是为了方便知识的组合与传递，提高其流转效率。

日常生活和工作中有很多知识封装的例子，如：语言、文字中各种类型的词汇；软件开发时定义的常量、变量、函数、类等。

既然要封装，就不应该出现一个海纳百川的符号——如果它什么都是，那它就什么都不是，实际不会起到任何真正有价值的正向作用。因此，要控制符号语义的边界，尽量恰到好处。

控制边界就是限制符号所封装的知识的复杂度以及传播途径——

遵循关注点分离、单一职责等原则提高符号的内聚性，如：软件的模块拆分、分层架构；工作岗位的横向、纵向职责划分——专人专事，别给某个岗位的人提不相关的要求，且拿那些不合理要求作为考核指标。

最少化输入/输出（I/O）通道以限制符号间的通信，降低并抑制混沌产生的概率——软件程序单元的 API 和参数要尽可能地少；某个小组或部门只让尽可能少的人（最好是只有一个）成为「必须知道（几乎）全部细节的人」。

这里有个可能比较容易疑惑的地方——人怎么就是「符号」了？

这是一个涉及到哲学、社会学、心理学的问题，就不在这里严肃认真地讨论了，简单说明就是——

一个人在认知他人时，会不可避免地根据对方表现出的特征、状态等进行标签化，进而聚合形成一个自己所认为的那个人的符号化形象。

并且，在与他人协作时，一个人的身份更大程度上不是他自己，而是他所处的包含且代表他的专业知识与技能、部门职责的工作岗位，这更加是符号了——某个职业、某个专业、某个部门、某个岗位等都是封装了特定知识的符号。

知识传播

假设知识被恰如其分地封装，以此为前提，大胆地掏出奥卡姆的剃刀——

用尽量精确且简单的符号去表达知识——「精确」是为了避免歧义，「简单」是为了易于理解，从而减少认知偏差，让协作的人之间在脑中所想象出的是同一个事物；在软件开发方面，则会缩减代码量，节省资源开销。

用尽量短的路径抵达终端——路径越长，到达终端的时间就越长，损耗失真得就越多，对时效性、完整性要求高的话会对终端产生很大影响。

知识维护

基于「唯一可信来源」（英文为「Single Source of Truth」，下文简称「SSOT」）思想对知识进行维护，其核心就是只认可某一个来源的知识，尊其为权威，不接受并无视其他来源，有种一神教的感觉。

这需要结合一定的强制性措施保障其能够执行到位，以杜绝同一知识出现多个版本；建立某种反馈控制机制，令所有消费了知识的环节都能在源头变了时响应式更新，并反向促进知识源头时刻保持最新。

若不遵从「SSOT」，定会出现同一知识有多个版本存在的情况——在协作时不仅会增加理解和沟通成本，促成拉锯扯皮甚至是争吵谩骂的状况；还会提高知识同步时的修正成本和维护成本，让人逐渐失去更新知识的动力。

遵从「SSOT」的知识是群体智慧的结晶，相对来说会提高知识的正确性和有效性。就算错，也是一错到底，要追责的话，不是某（几）个人的责任，而是知识维护的所有参与者的责任。

除了上述特点，遵从「SSOT」的知识总体上是采用中心化的管理方式，并能减少甚至避免显性知识分散与隐性知识丢失的状况，从而提高知识的完整性、可观测性。

问题分析

下面将用上文阐述的关于知识的基本原理去从知识的角度分析并解释在上篇文章中描述的那几个日常工作中的常见问题——

业务支持、岗位职责和跨部门协作中的问题主要是知识封装得不好，并且未被有效、顺畅地传播；测试左移的问题则在于知识维护上，在跨部门协作中也存在此类问题。

小结

本文总结了关于知识的几个基本原理，并基于它们从知识的角度解释了日常工作常见问题的原因。在下篇文章中，我将在本文所述的基本原理之上畅想解决那些常见问题的方案。

---

本文其他阅读地址：个人网站｜微信公众号