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

复杂模式 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. 通过预约目的的车次，能做的优化更多了

清晰模式 1. 编程语言的规则：语句「if、for、while、break」、类、方法等 2. 调用第三方接口：按说明文档对接「发送短信、支付、查询天气等」 3. 调用 HTTP 接口时检测到参数错误「长度、取值范围、类型等」，拒绝提供服务并返回错误信息 4. 单元测试/功能测试：针对指定功能编写的测试用例，从正常功能「happy path」、异常情况「sad path」、默认值「default path」等多个角度进行测试 庞杂模式 1. 选择一款适合自己的 AI 插件提升开发效率，感知「价格、流畅度、功能」，分析「AI 结果正确率、解决方案是否合理」，响应「从中选一款：Copilot、通义灵码、Double」 2. 开发 Android App 时使用什么语言「Java、Kotlin、Fluter、React」，一般情况下是当前 App 端程序员选一个自己熟悉的 3. 根据业务需求选择存储方案：程序中的内存空间、MySQL、Redis、MongoDB、Elasticsearch、InfluxDB 等 4. 通过错误日志排查 Bug、定位问题 5. 通过监测数据「API 总耗时、API 调用链、慢 SQL 等」优化系统性能 6. 根据用户的描述，排查问题「无法登录、无法支付、支付成功后没有收到商品、无法接收短信等」，并解决问题 7. 根据业务方的简述，实现功能，例如一个简单需求「实现用户登录功能」，实际包含：用户注册、登录、密码找回、短信验证、第三方登录等多个功能