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

Complicated和Complex在中文都可以被翻译为复杂，所以我特意查了一下这两个单词，其实是完全不同的原因导致的复杂。老师在这里巧妙的用庞杂和复杂来进行区分，以此强调一个复杂的原因在于“庞”，也就是大，因为大而导致的复杂，其本质还是一系列简单的堆叠，也就是多个清晰模式的组合，那么对于专业人士来说，仍然是简单的。 而复杂的原因在于“复”，也就是多，还有种交叉混合的感觉，让人分不清是什么东西。但这二者又是可以相互转换的，复杂在你抽丝剥茧、认知提高后，是能转换为庞杂的；同样，对于专业人员的庞杂问题，如果没有掌握前置知识，那么对于你而言，仍然需要进行的是复杂认知模式。 进一步来说，庞杂模式还是清晰模式是否也是可以转换的呢？我们可以看到，二者都是sense - * - response，主要区别就在于是分析还是归类，我觉得对于大脑来说，其实就是走高速专用神经通路还是低速通用神经通路，这个只要经过刻意练习，庞杂模式也是能转换为清晰模式的。 再进一步思考，这四种模式都是是一定包含感知和响应，区别就是在于顺序和剩下的一个表现不同，如果是归类就是清晰模式，如果是分析就是庞杂模式，如果是探测就是复杂模式，如果是行动就是混乱模式。 也就是说无论如何一定会进行感知和响应，那么感知和响应的顺序就很重要了，感知在响应前面的，都是有意识的行动，都是好的。只是因为认知的差别，导致了能不能直接进行感知，如果能感知就是清晰或者庞杂模式，如果不能感知，就只能探测，我觉得也可以叫试错，然后再感知，最后产生响应。 混乱为什么是不好的，因为它是响应在感知之前，由行动触发，也就是常说的后知后觉，往往会让人后悔或者遗憾，所以需要尽量避免。 最后提一下，自从TDD跟着徐老师学习之后，对我的代码品味产生了很大的影响。不知不觉已经两年了，一直在期待徐老师的新课，之前TDD虽然没有学完，因为我比较懒，只完成了容器的部分，后面chatgpt出来以后就更不想写自己手敲代码了，现在也想问一下老师现在还有必要按照TDD的模式进行开发吗？在AI时代有什么演进吗？

🤔☕️🤔☕️🤔 【R】CynefinFwk = Clear + Complicated + Complex + Chaotic + Confused（FC=5C） 清晰 -》庞杂 -》复杂 -》混乱 -》困惑 清晰/庞杂：感知（sense）-》归类（categorize）/分析（analysis）-》响应（respond） 复杂：探测（probe）-》感知（sense）-》响应（respond） 混乱：行动（act）-》感知（sense）-》响应（respond） 【.I.】情绪：无聊 -》烦人 -》紧张 -》慌张 -》慌乱 规则：遵照 -》选择 -》建立 -》定义 -》无序 我站在原地，我想去往某个目标。目标和路径明确，我有清晰感，很快我也会有无聊感，因为遵照着做就可以。目标在那里、路径得由我选择，我有庞杂感，每个拐弯的地方、每个路障的地方，都要我做出选择，真是有点烦人。目标有点模糊、要自己走出新路径，我有点紧张，立目标、建新路考验我的决断力，而每次决断都意味着责任。什么叫目标、什么算路径，我得自己定义，慌张感伴随我的每次呼吸。然后，在慌乱中，手放哪里都显得多余，脚每次挪动都无比笨拙，我被扔进无序的海洋，抓不住任何一根稻草，最让我困惑的是，不就是学门课程，至于如此嘛。 【Q】怎么能够提醒自己，当前处于怎样的认知行为模式，以及做出切换到更优模式的思考与判断？ — by 术子米德@2024年3月13日

教导别人设计模式，庞杂模式 自己学习设计模式，复杂模式

清晰：对一些已知的功能点写出TODOs，或者将这些TODOs转化为相应的test和code 庞杂：架构老鸟对业务功能需求分析、拆分为当前架构中的相应模块的功能点 复杂：初级工程师对如此功能的分析、拆分过程 此种行为模式（Probe-Sense-Respond）大概率将会是一种导致架构腐化：Probe大都结束于功能完成，non-Sense对架构的腐化过程

我之前理解复杂就是文中所说的庞杂，认知负荷(信息承载量不断增大+错综复杂的联系)。 而文中的复杂，却有一种对未知的探索，通过不断收集信息(知识)来梳理反思发现真正问题，这里是对信息承载量的补充，应该也算是一种(缺少信息量)庞杂吧

困惑模式没讲？

复杂模式 1. 业务方找了一家提供「第三方打款服务」的 A 公司，对接成功后，因单日打款金额超过阈值，触发了支付宝风控，支付宝账号被冻结。此时，A 公司表示他们的系统没有问题，是支付宝的问题，他们无能为力。 2. 在工作使用 TDD，刚开始的时候，困难远远大于收获，坚持一段时间后，终于迎来了收获大于困难 困难： 1. 不会任务分解，一个方法中包含了多个逻辑，导致编写测试用例的时候一脸懵，无从写起 2. 需要花更多的时间思考如何进行任务分解，比起「一把梭」的开发方式，开发期间每天都加班 3. 公司的项目有 20 多个，每个项目不能独立启动运行依赖 Spring 容器的功能测试，又是加班来解决这些问题 4. 核心交易是通过 MQ 进行流转的，一笔交易产生的数据分散在 3 个以上的系统中「财务、用户、统计、活动等」，后来新建了一个项目专门针对核心交易进行功能测试 收获： 1. 初步掌握了任务分解，可以编写出大量符合「单元原则」的方法，使用 Copilot 代替了 50% 的编码工作 2. 使「即使重构」成为了一种习惯，在迭代中代码变得越来越好 3. 学习 DDD 时，有能力使代码与模型保持一致 4. 加班找 Bug 的时间越来越少了 3. 想开发一款游戏增加收入，学习了 Unity、C#，突然发现很难申请到游戏版号，放弃了 4. 想开发一款 App，通过接入广告 SDK 实现盈利，正在学习 Android 的 Jetpack Compose 5. 12306 不断优化的节日抢票的解决方案 1. 同一时间开售全国所有车次，系统崩了 2. 分时间段销售不同目的的车次，系统正常了 3. 通过预约目的的车次，能做的优化更多了

清晰模式：完成确定性的小功能feature 庞杂模式：推动一个已经做过的专项 复杂模式：推动一个从未做过的专项 混乱模式：刚加入新团队就出线上大故障

鲲之大

清晰模式：在软件开发中，员工同步场景，就是一个典型的清晰模式 在这个场景中： 感知：识别、收集员工信息变化，包括员工入职、员工离职、职位晋升、薪资调整等 归类：将感知到的员工信息变化进行归类，以便能够正确映射到系统用户 响应：根据归类的员工信息变化，采取相应行动——增、删、查、改数据 庞杂模式：在财务类系统中，摊销计算，是一种庞杂模式 感知：识别上下文信息，包括开始计算期间、期数、摊销执行时间与起始期间的关系等 分析：分析感知到的上下文，以确定正确的摊销方法和金额 响应：将计算出的摊销金额记入适当的会计期间中，并针对性进行调整 复杂模式：在开发过程中，持续集成具有结果的不可预知性，可以看做是一种复杂模式 探测：监控代码仓库，感知提交新代码更改，触发自动构建流程 感知：对代码更改的理解和分析、评估影响包括静态分析、漏洞分析等 响应：根据感知到的信息采取行动，包括构建、测试和部署应用 混乱模式：混乱模式是一种反模式，但在敏捷实践中 Tech Spikes 这种看似“有枣没枣打三竿子”的技术勘察，可以看做是通过先行动以期快速重建秩序 行动：迅速行动，确定合适的技术栈和工具，并开始编写代码 感知：密切观察环境、测试数据和用户反馈，以便及时调整解决方案 响应：在感知的基础上，对技术、环境变化或反馈做出的适应性调整优化