03｜通过知识过程重新理解软件工程

Mar 13, 2024

03｜通过知识过程重新理解软件工程-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

03｜通过知识过程重新理解软件工程

徐昊 · 徐昊 · AI时代的软件工程

课程介绍



讲述：徐昊

时长10:08大小9.27M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
通过前面的学习，我们知道：
所谓知识过程，就是从知识管理的角度理解我们的工作，将我们的工作看作产生、传递、应用、消费知识的过程；
不可言说的知识是复杂工作中真正发挥作用的知识；
不可言说知识需要从经验中获取，很难通过语言或其他形式传播；
不可言说知识的学习与传递会产生不同的认知行为模式；
不同认知模式具有不同的效率。
那么，我们可以通过知识过程中，产生的不同知识，以及这些知识传递过程中产生的认知行为模式，来理解整个知识过程。通过不同认知行为模式，来理解整个知识过程的效率。
今天我们就将以软件工程为例，将它转化成知识过程，并识别其中的认知行为模式。
软件中包含的知识软件本身是载体，并不是真正的产品，真正的产品是包含在其中的知识。
在这一点上，软件与书籍是一样的。虽然站在读者的角度看，书籍是产品，但作家真正关心的并不是书，而是其中的人物、情节、故事线。对于非虚构书籍而言，可能是观点、结构、论据等。真正有价值的并不是书，而是书中所蕴含的内容。所以作家可能不会过多地考虑书是如何被印刷出来的，但是要对如何组织其中的内容深思熟虑。对于作家而言，内容才是真正的产品，书籍只是内容的载体。
对于软件，真正的产品是软件中所包含的知识，软件自身仅仅是知识的载体。
软件中包含的最重要的知识就是业务知识，也就是我们所说的业务流程、组织架构、行业规则、领域知识等等。这些知识描述了软件是如何帮助客户解决某一类问题，或是一家企业是如何运营其业务的，或是以何种形式与用户互动等等。
作为产品的业务知识可以脱离软件存在，但是作为载体的软件却不能脱离其内在的知识存在（技术上虽然可以，但是没必要存在）。那么，除了软件之外还有其他形式的知识载体吗？
一个显而易见的答案是人。纵然大部分情况下，在效率和成本上大大不如软件，但人一旦学会并掌握软件中所蕴含的知识，就可以提供与软件类似的能力。比如，按公式计算结果、产品报价、汇聚数据生成报表这些常见的软件功能。其中真正对应的产品是：计算所需的公式、报价规则和报表内在的数据逻辑。在学会这些知识后，人也可以完成相应的工作。
另一个类似的答案是按照流程规则交互的部门，或者说按照知识协作的组织。比如，商品支付、商品出库、商品上架等常见的功能流程。其中对应的真正产品是转账流程、商品出库登记与移交流程、商品上架登记与移交流程。同样，在掌握这些知识后，组织也可以完成相应的工作。
知识的三种载体
除去业务知识之外，软件中还包含关于“软件系统该如何实现”的知识，也就是我们所说的软件架构。架构定义了系统中组件的类型以及组件间交互的方式。架构有两个目的：帮助我们理解系统现状，以及当有新需求出现时我们要如何实现它们。
对于理解系统现状而言，架构知识是显式知识。它会通过不同的视图描述系统中具体的组件以及组件间的交互。
对于应对新需求的变化，需要将需求分解到对应的组件中去，并严格依照组件间的交互方式完成业务逻辑。此时，架构的主要作用是作为系统需求功能拆分的指导，是以不可言说知识的形式在发挥作用。
当然软件中还会承载其他的知识，比如软件的运营知识等等，但是从构造软件的角度上讲，最重要的两类知识就是业务知识和架构知识。一个是关于什么是“正确的软件”的知识，另一个则是关于“如何正确地构造软件”的知识。
将软件的研发过程构造为知识过程，就需要围绕这两种知识的提取与传递构造知识过程。
将软件研发过程构造为知识过程首先是业务知识，业务知识并不是软件的功能点。业务知识更多地体现为现实中要解决的问题，在现实中存在的限制与制约，以及现实中存在的解决方案。当业务知识通过软件这个载体呈现的时候，才会表现为软件功能点。
哪怕在业务上已经存在解决方案，映射为软件的时候，也不一定就与现实中的方案一致。比如现实中存在一个审批流程，那么通过软件呈现时，可以借由设立邮件组或微信群的方式支撑这个流程，也可以通过在 OA 系统中增加特定工作流的方式完成。
由于业务知识并不仅仅存在于软件中，人和组织中也会存在业务知识。当引入软件承担一部分业务知识时，或是修改软件所承担的业务知识范围时，也会引起对应的组织变更。比如，从邮件为主的办公环境，过渡到以微信为主的办公模式时，组织上的流程也会有所改变。
因而，在构造软件之前，我们无法 100% 确定所构造的软件是否能够满足业务的需求，是否能够在现有的知识结构下发挥作用。所以，软件研发的过程，从宏观上来看，是这些部落知识传递与学习的过程，只能是复杂的认知模式。
这也是为什么当今主流的研发流程，或多或少都包含迭代的元素。因为每一次迭代的过程，都是一次探测（根据已知情况构造软件）- 感知（收集反馈以验证当前软件是否有效）- 响应（根据反馈改进方案以及后续计划）的过程。
说句题外话，如果将软件过程放大到整个产品生命周期，那么我们可以通过精益创业（Lean Startup）的视角，将软件产品看作一个持续学习过程，即构建（Build）- 度量（Measure）- 学习（Learn）不断反复迭代的过程。这个过程仍然是复杂认知模式：构建（Build/Probe）- 度量（Measure/Sense）- 学习（Learn/Respond）。
进入交付流程之前，我们需要按照当前对于业务知识的理解，构造一个目标解决方案。这个目标解决方案可以是业务架构愿景或是选定的解决方案。然后按照目标解决方案将业务知识转化为软件需求，也就是将软件功能分配给不同的业务模块。
这是目标解决方案知识的应用，此时我们处在庞杂模式：感知（对于要解决的问题已有初步理解）- 分析（按照业务架构 / 解决方案处理问题）- 响应（得到不同软件系统的软件需求）。
一旦根据软件需求确立了研发 / 交付计划，进入交付流程之后，对于软件构造全部都会围绕质量展开。这包括功能性质量和非功能性质量两个方面。功能性质量关注软件是否能够执行其预定的功能。非功能性质量通常是用户不直接感知、但对整体用户体验至关重要的方面，比如性能、可靠性、可扩展性等等。
功能性质量由软件需求决定，而非功能性质量则是由架构知识决定的，软件架构的设计决策直接影响系统的性能、可扩展性和可靠性。架构知识也是一种目标解决方案，所不同的是，架构知识是从技术视角出发的解决方案，是针对性能、可靠性、可扩展性等问题的解决方案。
因为架构知识发挥作用的方式与目标解决方案类似，也是在任务分解过程中发挥作用，即将软件需求在架构所规定的组件范围内，进一步做任务分解。此时我们同样处在庞杂模式：感知（对于要解决的问题已有初步理解）- 分析（按照软件架构处理问题）- 响应（得到针对不同架构组件的任务）。
因而架构腐化并不单单指最终的结果，更多是在分解任务的时候，架构不能有效起到指导作用，持续产生不正确的任务划分，架构就会腐化。
在软件构造过程中，功能性和非功能性质量是相辅相成的。一个功能完备但性能低下的软件或者性能优异但功能缺陷多的软件，都不能算是高质量的产品。因此，软件团队需要平衡这两方面，确保软件不仅能够完成其核心任务，而且在性能、安全性、可用性等方面也能满足甚至超越用户的期望。
在实践中，这通常意味着在整个开发生命周期中要采用综合的质量保证措施，包括但不限于代码审查、多层次的测试策略、性能优化、安全分析等。不同的质量保证措施，实际也处在不同的认知行为模式上。
比如最常用的代码审查，这种质量保证措施建立在反馈的基础上，所以它处在复杂模式。代码审查涉及的行为是探测（由成员根据对架构的认知先完成功能）- 感知（由架构师或团队其他成员对于已完成的功能进行反馈与评价，寻找不符合架构约束的地方）-响应（指明整改和改进的方向）。
与之对应，测试策略的基础是分析情况并挑选正确测试方式，因此是一种处在庞杂模式的质量保障措施。测试策略的行为是感知（理解需要解决的需求边界）- 分析（将需求功能按不同边界，分解为不同种类的测试）- 响应（最后根据分解的结果完成测试）。
小结通过前面的讨论，我们可以从知识传递的角度这样来理解软件工程：
从宏观过程来看，软件研发的过程是一个对于业务知识学习的过程，是复杂认知行为模式。
进入到交付过程之前，我们需要将业务知识转化为软件功能需求，这是目标解决方案的应用，是一个不可言说知识应用的过程，是庞杂认知行为模式。
架构知识也可以看作是从技术视角出发的解决方案。按照架构构造软件的过程，是一个不可言说知识应用的过程，是庞杂认知行为模式。
在软件构造过程中，功能性和非功能性质量保障措施会带来不同的认知行为模式。
理解了软件工程中的知识传递，与它们带来的不同认知行为模式，我们自然可以评价不同的研发方法带来效率的差别。我们工作中常用的方法，可能是低效的，而看起来奇怪的方法可能是高效的。
比如，Debug 实际是低效的复杂认知行为模式，探测（打断点）- 感知（通过断点周围的数据和调用栈，寻找问题成因）- 响应（定位问题）。
Debug 实际表示我们并不知道代码到底是如何运转的，正在学习当前代码库。而看起来奇怪的测试驱动开发（Test Driven Development）则是庞杂认知行为模式。
将软件开发过程理解成知识过程，更重要的作用，则是帮助我们更进一步理解 LLM 能带来哪些改变，这是我们在后面要学习的内容。
思考题请从知识传递的角度，分析你所处的团队有哪些低效的行为？
欢迎在留言区分享你的想法，我会让编辑置顶一些优质答案供大家学习讨论。

软件工程的知识过程重新理解，强调软件本身是知识的载体，而非真正的产品。文章指出软件中包含的最重要的知识是业务知识和架构知识。业务知识描述了软件如何帮助客户解决问题，而架构知识则定义了系统中组件的类型和交互方式。除了软件，人和组织也可以成为知识的载体。通过不同认知行为模式，可以理解整个知识过程的效率。因此，将软件的研发过程构造为知识过程，需要围绕这两种知识的提取与传递构造知识过程。软件研发的过程是一个对于业务知识学习的过程，是复杂认知行为模式。进入到交付过程之前，需要将业务知识转化为软件功能需求，这是目标解决方案的应用，是一个不可言说知识应用的过程，是庞杂认知行为模式。架构知识也可以看作是从技术视角出发的解决方案。在软件构造过程中，功能性和非功能性质量保障措施会带来不同的认知行为模式。理解了软件工程中的知识传递，与它们带来的不同认知行为模式，可以评价不同的研发方法带来效率的差别。文章通过对软件工程的知识过程进行重新理解，为读者提供了新的思考角度，帮助他们更好地理解软件工程的本质。

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

2024-03-13

赞 17

提建议

02｜知识过程中的认知模式

04｜使用LLM提取和传递知识

 写留言

全部留言(16)

最新
精选

术子米德
2024-03-15 来自浙江
🤔☕️🤔☕️🤔 【Q】从知识传递的角度，分析所处团队有哪些低效的行为？【A】首先，缺少一门课程，把行为认知相关的显性知识，清晰无误地分享给团队小伙伴，让大家知道，接下去遇到的文档，基本就是清晰（Clear），各种基于PPT、临场发挥不少的分享，基本就是庞杂（Complicated），实际在推进的项目，经常改来改去的需求，基本就是复杂（Complex），发布后的各种问题，基本就是混乱（Chaotic），运行好好的系统忽然故障，基本就是困惑（Disorder）。其次，大家要明白，不同的行为认知模式下，不可言说知识所占的比例不同，实际经验是，它的占比越来越高，甚至有天赋和灵感的展现，也无需惊讶，更不要羡慕，这是持续经验在肌肉里积累的记忆。最后，在行为认知规律下行事，别抱怨这没有那不行，负面情绪是最低效的知识传递行为。 — by 术子米德@2024年3月15日
展开
编辑回复: 交流群里老师做了点评，这里也同步一下： chaotic最常见的形式是没有明确验收条件只有deadline的需求。chaotic是应激（处在应激的时候是恐惧的，做的行为是为了恢复秩序感），根本解决不了问题，还是提醒：所有对于cynefin的使用，都要按行为模式找，不要对问题分类。比如同样是看文档，可能是probe，比如不知道怎么做；可能是category，比如线上问题，明确问题等级，寻找应急预案；可能是analysis，对比历史方案；所以，看文档可能是clear，complicated，complex，甚至是chaotic。
共 2 条评论
4
一只豆
2024-03-13 来自广东
这一课像是个捧哏，勾的我贼期待下一篇～
编辑回复: 这比喻真酷
aoe
2024-03-13 来自陕西
1. 宁可加班找 Bug，也不愿意学习 TDD 2. 宁可加班堆功能，也不愿多理解一点需求 3. 不仅一次因欠费导致服务无法正常运行，偶尔还是会出现 4. 任职期间疯狂复制粘贴代码，运气好点加班改 Bug，运气不好自己都待不下去了 5. 相信产品说：需求不会变了 6. 使用百度搜索问题，看了很多看起来有道理但就是不能解决问题的回答 7. 不使用 AI 辅助编程，坚持纯手工 8. 盲目追求「微服务」，原来很多简单的事情，变的无比复杂 9. 以为用了 K8S 就能各大云厂商一键部署，结果支付给云厂商的费用更多，稳定性、吞吐性能、服务监控都不如云上已有的服务。 10. 时间紧多找几个人一起实现功能，实现的第一版在预期范围内，后面改来改去，谁改谁害怕
展开
12
临风
2024-03-13 来自广东
我们做事情常常希望能找到第一性原理，这样就能认识到事物的上限和边界，也就不会产生妄念，指望通过低效的方法达到高效的结果。我不知道老师将认知模式运用到软件工程算不算真理，是不是软件工程的本质，但我觉得这个理论至少提供了一个很好的思维框架，帮助我们去理解软件工程的本质。软件工程在我看来就是为了去解决日益增长的软件规模和逐渐复杂的人员分工之间的矛盾，这个矛盾又集中体现在知识传递的过程。也就是我们常常会发现，一个功能需求，其实不是技术实现上有多难，而是因为软件规模过于庞大，以至于个人不能掌握全部的上下文信息，而复杂的分工，又导致开发者很难串联起全流程，站在客户的使用场景，去开发一个完美解决客户问题的软件产品。认知模式的分类，给了我们一个很好的认识视角。首先，知识传递的效率，很明显是清晰模式 > 庞杂模式 > 复杂模式 > 混乱模式。回到开发场景，清晰模式就像搜索答案，它效率应该是分钟级的；庞杂模式就像一个老手接到需求，他能很快知道要做什么事情，并分析清楚各个业务场景和边界条件，效率是小时级的；而复杂模式就类似一个新手接到需求，完全是懵的，需要不断的问别人，不断的探测，它的效率常常是按天来算的；混乱模式就更别提了，效率基本未知，完全无法预测需要多长时间，甚至花了很多时间都无法认识到问题的原因。所以软件工程要做什么，就是尽量把复杂模式变为庞杂模式，把庞杂模式变为清晰模式。我猜老师后续就是要回答，AI时代如何升级认知模式，如何让认知效率产生质变，期待后续的内容^-^
展开
共 1 条评论
10
大卫
2024-03-17 来自浙江
通过代码执行过程来了解软件架构 VS 通过软件架构来了解代码执行过程：大概每个刚入行的菜鸟都想一头扎进代码，恨不得马上debug起来——不理解架构甚至不理解业务知识，这可认为是最低效行为
3
术子米德
2024-03-15 来自浙江
🤔☕️🤔☕️🤔 【R】软件=书籍 is 载体，知识=内容 is 产品。软件知识 = 业务呈现知识 + 技术架构知识。业务侧学习过程是复杂认知行为模式，从探测（Probe）已知开始，到感应反馈、再响应改进的复杂过程。技术侧设计过程是庞杂认知行为模式，从感知（Sense）问题开始，到分析解决方案、再响应软件需求的庞杂过程。【.I.】所需、所能，面对你所需、看看我所能，所需用软件呈现的业务，所能用技术做出的功能和达到的品质。假设，面对所需，我因不熟悉业务，也因无人已经为目标梳理通所有的业务所需呈现的样子，那么我能做的就是，从接触到部分开始，先做下去，先呈现出个样子来，基于此从已知向未知探测，或基于此修正对所谓已知的误解，我的情绪主调是紧张。此时，有个隐式的假设，那就是我的所能是个超集，它大于当前已知所需、以及探测出来的新所需，它们已经或即将要的所能，我的情绪主调是烦人。可实际上我发现，我的所能从未如此。所需越是展开，发现所能越是匮乏，情绪里慌张感逐步积累，跨进慌乱感的时刻，往往是发现原来的业务分析，在新的视角下看来，其实都不合理，甚至可以说全是错的。推倒重来，继续糊墙，这就是个问题。如果在此之前，只有实现代码，那绝无重来的勇气；如果有实现代码、还有验证代码，即所谓TDD的践行者，那么心理上可以推倒，实际无力重来；如今LLM based Coding Assistant上场，说来一起先审阅一下验证用例，再一起加固下验证代码，然后直接删除旧实现代码，由它，AigCoder来没日没夜重写实现，只要符合验证用例，至少会有一份功能一致的新代码，这就是开发新范式的诞生。【Q】不可言说知识的应用，是否在每个认知行为模式下都存在，只是比例多少的问题？ — by 术子米德@2024年3月14日
展开
2
需要练习的码农
2024-06-12 来自北京
代码审查对于不同团队有可能处于不同的认知行为模式么？例如庞杂模式，感知-分析-响应。
范飞扬
2024-04-18 来自广东
目标解决方案的定义是：为实现目标做的方案，包含整体解决方案和用户旅程。请教一下老师和各位同学，我这样理解对嘛
共 4 条评论
zenk
2024-03-23 来自上海
告警规则设置，不同服务业务不一样，需要不同的告警，缺少服务的slo明确定义，先定义一个再说，爆出来来了再调整。。。
Jaising
2024-03-23 来自浙江
1、代码写注释，尤其是写大量的注释 2、部分代码红网管控，只允许代码在少部分人之间流动，对外部一概不透明，甚至没有 API 3、基于流而不是基于主题、实时（响应更快）优于异步（吞吐量更大、方案更优）的协同软件，微信群一样的组织工作，消息与文档散落各处，反过来又使协同软件支持富文本全文检索、一键呼叫、已读这样的功能 4、没有时长限制、没有会议议程预审的会议软件来组织跨部门会议

