知识工程视角下的软件研发

知识工程

在我们的工作中存在两类知识：显式知识（explicit knowledge）、不可言说的知识（tacit knowledge）。

所谓显式知识就是能够直接表达且在人群中分享的知识。比如，地球的周长、水的密度、三角形面积公式等等。
不可言说的知识是指那些不易用言语表达或形式化的知识，它通常是个人经验、直觉或技能的一部分，与个人的认知和学习过程紧密相关。

不可言说知识通常更为重要。
例如，在一个软件开发团队中，不可言说的知识可能包括特定的编码实践、项目管理的非正式流程、代码审查的潜规则，甚至是如何有效地与特定同事沟通的技巧。这些知识通常不在任何手册中，但对于新成员快速融入团队、提高工作效率和质量至关重要。

不可言说知识的传递

当代知识管理理论认为，社会化活动（Socialization）是传递不可言说知识的不二法门。
社会化活动最常见的形式是启动-反馈循环（kickoff-feedback cycle）。在启动阶段（Kick off） 时传递知识，在反馈（feedback）时检查知识是否被吸收并且转化成为实际的产出物。反馈中还要包含针对思维过程的反馈，或是知识消费者对思维过程的自省。
另一种特殊的社会化活动是训练法。也就是将不可言说知识转化为教程、dojo、或者挑战练习等方式。通过一系列启动-反馈循环，持续且稳定地完成不可言说知识的传递。
对于软件架构，一个最常见的错误是，架构师通常只会提供架构文档，以说明当前架构的现状，但很少为架构提供教程或使用手册。也就缺乏针对在不同场景下，如何应用架构中的概念解决问题的指引。缺乏训练法，架构中的不可言说知识就无法持续稳定地传播。这是很多架构腐化或是无法落地的根因。

与知识消费有关认知行为模式

所谓认知模式，就是指人利用知识进行决策时，采取的行为模式。我们可以使用Cynefin框架理解不同知识消费和传递中产生的不同认知行为模式。
根据2020版Cynefin框架的定义，这五个领域分别是：清晰（Clear）、庞杂（Complicated）、复杂（Complex）、混乱（Chaotic）和困惑（Aporetic/Confused）。利用这五个领域，可以帮助我们更准确地评估情况，并做出适当的反应。

首先是清晰（Clear）的认知行为模式。这种行为模式也被称作已知（Known）或显然（Obvious）模式。当处于清晰模式时，要解决的问题是稳定且具有清晰的因果关系。每个人都能轻易辨别，正确答案往往不言自明，无可争议。处在清晰模式时，认知行为表现为：感知（sense）- 归类（categorize）- 响应（Respond）。

庞杂（Complicated）的认知行为模式也叫专家模式。庞杂模式与清晰模式不同，它可能包含多个正确答案，尽管因果之间存在明确的关系，但并非每个人都能看清。当处在庞杂模式时，对于要解决的问题，解决方法目前并不明确，在寻找解决方案的过程中，经验与分析能力发挥关键作用。这种方法并不容易，往往需要专业知识。因而被称作专家模式。
在庞杂模式下，认知行为表现是感知（sense）- 分析（Analysis）- 响应（Respond）。

复杂认知行为模式是反思模式，它表现为：探测（Probe）- 感知（Sense）- 响应（Respond）。只能通过探测收集必要的信息，再通过反思感知，最后采取必要响应，调整之前的方案。
当处在复杂模式时，对于要解决的问题，并不知晓是否能够解决。无论前期做多少准备，都不能确保存在解决方案，而是需要依赖反思改进。因此复杂模式也被称作“未知的未知数”。

最后是混乱模式，某种程度上说，这是个反模式。它表现为：行动（Act）- 感知（Sense）- 响应（Respond）。混乱模式的主要目的是通过快速行动重新建立秩序，尽快回到前面三种模式当中。因而混乱模式不是基于知识的反应，而是应激式的反应。

软件工程

对于软件，真正的产品是软件中所包含的知识，软件自身仅仅是知识的载体。

从知识传递的过程来理解软件工程

• 从宏观过程来看，软件研发的过程是一个对于业务知识学习的过程，是复杂认知行为模式。
• 进入到交付过程之前，我们需要将业务知识转化为软件功能需求，这是目标解决方案的应用，是一个不可言说知识应用的过程，是庞杂认知行为模式。
• 架构知识也可以看作是从技术视角出发的解决方案。按照架构构造软件的过程，是一个不可言说知识应用的过程，是庞杂认知行为模式。
• 在软件构造过程中，功能性和非功能性质量保障措施会带来不同的认知行为模式。

理解了软件工程中的知识传递，与它们带来的不同认知行为模式，我们自然可以评价不同的研发方法带来效率的差别。我们工作中常用的方法，可能是低效的，而看起来奇怪的方法可能是高效的。
比如，Debug实际是低效的复杂认知行为模式，探测（打断点）- 感知（通过断点周围的数据和调用栈，寻找问题成因）- 响应（定位问题）。
Debug实际表示我们并不知道代码到底是如何运转的，正在学习当前代码库。而看起来奇怪的测试驱动开发（Test Driven Development）则是庞杂认知行为模式。

认知分歧

在团队中，对于同一个问题，有的人处在庞杂认知模式，而另外一些人则处在复杂的认知模式中。我们还是以软件开发中的架构知识为例，对于架构师而言，应用某个架构实现功能，是处在庞杂认知模式。他可以按照架构的要求，对需求进行进一步分解，从而在架构的指导下，完成功能。而对于新加入团队的成员而言，可能处于复杂认知模式，也就是需要先实现功能，再根据组员或架构师的反馈，逐步修改代码以符合架构的要求。
对于团队而言，效率的根源在于知识传递的效率，即知识传递的准确性，一致性和及时性，这些极大地影响着团队的效率。

知识过程下的软件研发实践

1. 软件开发绝大部分活动都应该处于有序的状态（清晰或庞杂），严格控制无序状态的成本。

这里需要强调的一个概念就是有序和无序，我们将认知行为模式分为有序——清晰和庞杂，以及无序——复杂和混沌两类。比较这两类认知行为模式就会发现，有序的行为模式是感知（sense）在先，而无序的行为模式则是行动在先，感知在后。对应到复杂的行为模式就是探测-感知，对应到混沌就是行为-感知。
这意味着什么呢？这意味着当我们处于有序的认知行为模式时，我们对于要解决的问题是有定义的，可能对于解决方案不太了解。而处于无序的认知行为时，我们甚至不清楚要解决的问题是什么。

那为什么要严格控制无序状态的成本呢？这是因为，当我们处于无序的活动时，不仅仅成本很高，而且时间不可控。仔细想一想无序的两个行为模式，无论是复杂还是混沌，实际上都缺乏对于待解决问题的理解。本质上讲，我们就是不会，不能胜任，我们就是在学习。学就要分学得会和学不会两种情况了。这意味着，我们可能无法完成要解决的问题。
那么站在管理的角度上来看，任何无序的认知活动，实际都是项目风险，不光是质量风险，更是进度风险。于是对于这类活动最常见的管理方式，就是卡住时间——给予一定的时间，如果无法解决，那么就要立即止损。
止损的方式包括换人、寻找外援等等。我想大家都有过看起来简单，实际是大坑，最后造成项目严重延期的经历。这实际上告诉我们，当我们处在无序认知的时候，不要相信自己的判断，理想的做法就是及时止损。

2. 结对编程（Pair Programming）
   结对编程可以促进实时讨论和交流，从而使得不可言说知识更容易被理解和吸收。一名程序员可以向另一名程序员解释他的思维过程、选择和决策背后的逻辑，从而使得不可言说知识得以更清晰地传达。
   结对编程还可以通过反馈机制来加深程序员对不可言说知识的理解和掌握。当一名程序员使用不可言说知识时，另一名程序员可以提出问题、提供反馈和建议，从而帮助他们更好地理解和应用这些知识。最终有效地拉齐认知分歧。