23｜团队开发的核心模式

Apr 29, 2024

23｜团队开发的核心模式-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

23｜团队开发的核心模式

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

课程介绍



讲述：徐昊

时长06:17大小5.75M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
在这章前面的 8 节课中，我们讲解了使用大语言模型（Large Language Model，LLM）辅助软件开发的核心思路，也就是使用测试驱动的方法与 LLM 进行结对编程。然后我们依次引入了测试策略以及测试工序，帮助我们逐渐提高 LLM 生成代码的质量，让 LLM 写出符合我们架构要求的代码。
今天，让我们站在团队的角度上，来总结一下，在软件开发过程中的两个核心知识过程，即技术方案的应用以及软件质量的保证。
技术方案的应用宏观上讲，编码的过程是技术方案应用的过程。除了要实现特定的功能之外，对于如何实现这些功能也有具体的要求，也就是要符合技术方案中提出的约束与条件。
我们在业务知识管理的过程中，主要关注点在理解业务的需求，明确要解决的问题等等。而在具体的开发过程中，关注的重点，就变成了如何保证实现代码与技术方案要求是一致的。
通常而言，对于技术方案的应用处于庞杂的认知行为模式（Complicated）。理解业务需求就是感知（Sense），按照技术方案分解任务就是分析（Analysis），依照任务列表完成代码就是响应（Respond）。
对于技术方案的应用处于庞杂模式，给了我们两个极为重要的洞见。第一，作为不可言说知识的技术方案，需要预先被提取出来。也就是说，进入到开发环节时，我们主要是不可言说知识的应用，而不是不可言说知识的学习；第二，由于应用技术方案处于庞杂认知模式，那么效率的关键是团队的放大效应，而不是个人的有效性和效率。
对于技术方案的提前提取和准备是非常重要的。这意味着在项目开始之前，团队需要花费时间来研究和理解可能适用的技术方案，以及它们如何适应特定的业务需求。比如，是采用微服务架构还是单体架构。如果是微服务架构，服务的边界大致是什么样子的等等；再比如，系统是如何部署的，弹性边界是如何划分的，是可用性优先还是一致性优先等等。
但是更重要的是，我们要将这种不可言说知识形成团队共识（团队放大）。否则，团队中就会出现认知分歧。所谓认知分歧，是指一部分人处在庞杂认知行为模式，另一部分人处于复杂的认知模式。那么处于低认知行为的团队成员，就会引入质量缺陷，带来效率的损失。
比如，如果团队中有的成员不能理解团队要求的技术方案，那么他们就极有可能写出功能正确但是不符合技术方案的代码。这样的代码实际是存在质量缺陷的代码。质量缺陷可能体现在跨功能特性的缺失，丧失可扩展性，引入不恰当的耦合等等。早晚都会导致返工与重做。
因而，对于技术方案的应用，从团队水平来看，应该达到庞杂的认知行为模式，才能保证技术方案的顺利落地。这是从知识工程角度看待技术方案落地时，自然而然产生的结论。
当然，这与我们平时工作的实际情况会存在很大的出入。大把的架构师将精力放在技术方案的提前提取和准备上，而忽略了在团队中认知行为基线的建立。于是，我经常给他们讲一个神雕侠侣里的故事。
神雕侠侣里公孙止有一套奇怪的武功可以闭穴，但是条件极为苛刻，需要戒忌荤腥。于是在与杨过比武的时候，裘千尺就咬破了手指滴血到两碗茶里，给他和杨过喝，这样他的功夫就破了。裘千尺就跟公孙止说，我早说过你这功夫难练易破，所以不练也罢。
类似地，架构师的工作很多时候跟公孙止一样，虽然他们费尽了心思，为满足各种约束设计了巧妙的技术方案。但是开发却无法有效地应用这些知识，无法写出满足技术方案的代码，再巧妙的方案也就破了（落不了地）。所以我也对他们说，你们的方案 / 架构 / 框架，难练易破，不练也罢。
正如 Peter Drucker 所说，知识工作者的效率是知识消费的效率，而非知识生产的效率。知识工程也要从消费的角度去衡量工程的效率。如果无法构建高效的消费渠道，那么 title 光鲜的架构师，也不过是一个个破了功的公孙止罢了。
软件质量的保证除了应用技术方案之外，我们还需要关注软件的质量。软件的质量有一点较为特殊，那就是它是适用性质量，而非符合性质量。
符合性质量概念以符合现行标准的程度作为衡量依据，“符合标准”就是合格的产品质量，符合的程度反映了产品质量的水平。
比如说我做一个杯子，没什么特别的要求，也不是我神经质的艺术作品，就是普普通通的一个杯子。那么就需要高矮长短，大小胖瘦等等一干质量属性，我做好了可以拿着质量标准来对比，一眼就可以看出哪里出了什么问题。也就是通过是否符合这些标准，判断产品是否达到相应的质量。
而适用性质量概念以适合顾客需要的程度作为衡量的依据，从使用的角度定义产品质量，认为质量就是产品的“适用性”，是“产品在使用时能够成功满足用户需要的程度”。质量涉及设计开发、制造、销售、服务等过程，形成了广义的质量概念。比如，一件工艺优秀但是不合身的衣服，就是适用性质量不足而符合性质量满分的产品。
软件的基本质量就是要在用户使用的过程中发挥价值，支撑客户的业务发展。也因为软件“软”的特性，客户对于软件质量的期待，是有持续性的，是可以“持续满足业务发展诉求”的。那么，“可根据业务的改变持续演化”就是软件的基础质量要求之一。
因此，软件的质量并不是由后验式的质量检查决定的，而是由软件开发的过程决定的。在软件开发的过程中，需要为软件的持续演化提供基础的支撑，这也决定了软件的质量。
这就是 Edwards Deming 的质量管理理论。他认为，优秀的结果不是偶然发生的，而是通过管理和改进过程来实现的。也就是著名的内建质量（Build Quality In）。
显而易见，测试策略（Testing Strategy）是我们实现质量内建的重要手段。特别是“用以支撑团队的测试”，是软件可持续演化的重中之重。
与技术方案类似，通常对测试策略的应用也是庞杂的认知行为模式（Complicated）。因而，它也是不可言说知识的应用，而不是不可言说知识的学习；效率的关键是团队的放大效应，而不是个人的有效性和效率。它同样会产生团队的认知分歧，以及由此带来的质量缺陷和效率损失。同样的，QA（而非 Tester）也容易成为一群公孙止。
小结从知识过程看待团队软件开发时，知识的传递很容易就成为团队效率的瓶颈，再优秀的实践，都会因为认知分歧的存在，让我们陷入“公孙止困境”。而大语言模型恰恰可以在知识传递上，给我们带来极大的改进。核心模式就是利用思维链（Chain of Thought，CoT）作为可复用的认知提升工具。
如上图所示，具备高认知能力的人，以思维链 + 任务模板的形式将不可言说知识构造为可以传递的形态。认知能力较低的，则通过使用思维链，获得生成的任务列表，检查任务列表，并按照任务列表的指引，使用对应的任务模板，完成任务。
这里需要注意的是，对于认知能力较低的人来说，当他们第一开始使用思维链 + 任务模版时，并不能直接处于庞杂认知模式。他们更多仍然是处于复杂的认知行为模式，也就是对于不可言说知识的学习状态。但是这时学习的内容发生了改变。他们学习的主要内容是思维链中包含的思路和工作方法。
也就是说，他们学习的不是如何实现某个功能，而是技术方案是如何被应用的。这时候，通过 CoT 拆分任务，以及围绕任务列表进行反馈，就构成了一个反馈的循环。加速了他们对于不可言说知识的掌握。
而当他们逐渐掌握 CoT 中的思路时，他们才能对于任务列表的质量给出准确的判断，他们也就进入了庞杂的认知行为模式。团队中的认知分歧也就消除了。
思考题想一想，测试工序是如何将架构和测试策略结合在一起的。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家学习讨论。

1. 软件开发过程中的核心知识过程包括技术方案的应用和软件质量的保证。 2. 团队需要在项目开始之前花费时间研究和理解可能适用的技术方案，形成团队共识，避免认知分歧导致质量缺陷和效率损失。 3. 软件的质量是适用性质量，需要在软件开发过程中提供基础的支撑，以持续满足业务发展诉求。 4. 质量内建（Build Quality In）是软件质量的关键，而不是由后验式的质量检查决定。 5. 测试策略是实现质量内建的重要手段，需要支撑团队的测试，以保证软件的可持续演化。 6. 效率的关键是团队的放大效应，而不是个人的有效性和效率。 7. 软件的质量管理理论强调通过管理和改进过程来实现优秀的结果，需要质量内建。 8. QA（而非Tester）也容易成为一群公孙止，需要注意团队的认知分歧和质量缺陷。

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

生成海报并分享

2024-04-29

赞 1

提建议

22｜通过测试工序提高LLM代码质量

24｜构造基于语义的自动化脚本

 写留言

全部留言(4)

最新
精选

6点无痛早起学习的和...
2024-05-05 来自北京
所以其实我理解，现在的我们（读者）其实就处于一种低认知的层度，去学习如何 TDD 开发+LLM 结队编程，通过 LLM 的 CoT
术子米德
2024-04-30 来自浙江
🤔☕️🤔☕️🤔 【Q】测试工序是如何将架构和测试策略结合在一起的？【A】设计成怎样的架构，采用怎样的测试策略，这两样确定下来，测试工序难道不是由此确定？架构设计是主因，测试策略是次因，测试工序是这主次因决定的果，难道不是嘛？ — by 术子米德@2024年4月30日
术子米德
2024-04-30 来自浙江
🤔☕️🤔☕️🤔 【R】技术方案的应用（=编码的过程），问题点：如何保证实现代码与技术方案的一致性。认知模式：庞杂（Complicated）= Sense（业务需求）+ Analysis（任务分解）+ Respond（完成代码）。适用性质量（=适合顾客需要的程度为衡量依据）。高认知，生成思维链和任务模板，低认知，使用思维链和任务模板。【.I.】架构偏离，架构师讨论时喊去走个场，架构设计文档需要时拿出来摆个样子，顶多也就看一眼其中的分层模块拆解视图，等到系统跑出各种“xyz-bility”问题后，异口同声这是架构问题，包括架构师自己也跟着喊，情何以堪。知识消化不良，的确是个问题，架构师只会做粗粮，架构师自己都不肯吃自己的狗粗粮，谁还会这么舔狗般非吃不可。路径依赖和内心羡嫉是另外两个不容易拿出来说的因素，因为它们直指Team Leader。要破这样的局，难于开新局。【.I.】软件，软件产品，不同。软件，是手段，软件产品是目的。嵌入式产品里的软件，它是手段，软件产品里的软件，它是手段。当软件产品简称为软件时，它是目的。【Q】技术方案，输入要啥，输出怎么干，顶多再加些为何这么干，其中怎么干里面，已经包含由怎么样技能的人或团队来干，以及如何验证通过可集成的设计与定义，为何在技术方案的应用里，还要Sense业务需求、还要Analysis任务分解？难道技术方案只是张草图，没有分析完业务需求、设计的技术方案没有考虑到技术团队的分工协作嘛？【Q】高认知，设计出来的思维链和任务模板，如果还需要低认知的人来应用，是否表示高认知并未把不可言说知识，构造得不够充分？若在思维链和任务模板里，充分构造出不可言说知识，那么就能进入清晰认知模式，下游直接用LLM来生成即可，无需再要低认知的人来参与？ — by 术子米德@2024年4月30日
展开
aoe
2024-04-29 来自浙江
有了测试工序，架构师不是一个人在战斗，可以让小弟按自己规划的路线，冲锋陷阵。小弟通过使用思维链，获得生成的任务列表，检查任务列表，并按照任务列表的指引，使用对应的任务模板，完成任务。

