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

这一课像是个捧哏，勾的我贼期待下一篇～

我们做事情常常希望能找到第一性原理，这样就能认识到事物的上限和边界，也就不会产生妄念，指望通过低效的方法达到高效的结果。我不知道老师将认知模式运用到软件工程算不算真理，是不是软件工程的本质，但我觉得这个理论至少提供了一个很好的思维框架，帮助我们去理解软件工程的本质。 软件工程在我看来就是为了去解决日益增长的软件规模和逐渐复杂的人员分工之间的矛盾，这个矛盾又集中体现在知识传递的过程。也就是我们常常会发现，一个功能需求，其实不是技术实现上有多难，而是因为软件规模过于庞大，以至于个人不能掌握全部的上下文信息，而复杂的分工，又导致开发者很难串联起全流程，站在客户的使用场景，去开发一个完美解决客户问题的软件产品。 认知模式的分类，给了我们一个很好的认识视角。首先，知识传递的效率，很明显是清晰模式 > 庞杂模式 > 复杂模式 > 混乱模式。回到开发场景，清晰模式就像搜索答案，它效率应该是分钟级的；庞杂模式就像一个老手接到需求，他能很快知道要做什么事情，并分析清楚各个业务场景和边界条件，效率是小时级的；而复杂模式就类似一个新手接到需求，完全是懵的，需要不断的问别人，不断的探测，它的效率常常是按天来算的；混乱模式就更别提了，效率基本未知，完全无法预测需要多长时间，甚至花了很多时间都无法认识到问题的原因。 所以软件工程要做什么，就是尽量把复杂模式变为庞杂模式，把庞杂模式变为清晰模式。我猜老师后续就是要回答，AI时代如何升级认知模式，如何让认知效率产生质变，期待后续的内容^-^

1. 宁可加班找 Bug，也不愿意学习 TDD 2. 宁可加班堆功能，也不愿多理解一点需求 3. 不仅一次因欠费导致服务无法正常运行，偶尔还是会出现 4. 任职期间疯狂复制粘贴代码，运气好点加班改 Bug，运气不好自己都待不下去了 5. 相信产品说：需求不会变了 6. 使用百度搜索问题，看了很多看起来有道理但就是不能解决问题的回答 7. 不使用 AI 辅助编程，坚持纯手工 8. 盲目追求「微服务」，原来很多简单的事情，变的无比复杂 9. 以为用了 K8S 就能各大云厂商一键部署，结果支付给云厂商的费用更多，稳定性、吞吐性能、服务监控都不如云上已有的服务。 10. 时间紧多找几个人一起实现功能，实现的第一版在预期范围内，后面改来改去，谁改谁害怕

🤔☕️🤔☕️🤔 【R】软件=书籍 is 载体，知识=内容 is 产品。 软件知识 = 业务呈现知识 + 技术架构知识。 业务侧学习过程是复杂认知行为模式，从探测（Probe）已知开始，到感应反馈、再响应改进的复杂过程。 技术侧设计过程是庞杂认知行为模式，从感知（Sense）问题开始，到分析解决方案、再响应软件需求的庞杂过程。 【.I.】所需、所能，面对你所需、看看我所能，所需用软件呈现的业务，所能用技术做出的功能和达到的品质。 假设，面对所需，我因不熟悉业务，也因无人已经为目标梳理通所有的业务所需呈现的样子，那么我能做的就是，从接触到部分开始，先做下去，先呈现出个样子来，基于此从已知向未知探测，或基于此修正对所谓已知的误解，我的情绪主调是紧张。此时，有个隐式的假设，那就是我的所能是个超集，它大于当前已知所需、以及探测出来的新所需，它们已经或即将要的所能，我的情绪主调是烦人。 可实际上我发现，我的所能从未如此。所需越是展开，发现所能越是匮乏，情绪里慌张感逐步积累，跨进慌乱感的时刻，往往是发现原来的业务分析，在新的视角下看来，其实都不合理，甚至可以说全是错的。推倒重来，继续糊墙，这就是个问题。 如果在此之前，只有实现代码，那绝无重来的勇气；如果有实现代码、还有验证代码，即所谓TDD的践行者，那么心理上可以推倒，实际无力重来；如今LLM based Coding Assistant上场，说来一起先审阅一下验证用例，再一起加固下验证代码，然后直接删除旧实现代码，由它，AigCoder来没日没夜重写实现，只要符合验证用例，至少会有一份功能一致的新代码，这就是开发新范式的诞生。 【Q】不可言说知识的应用，是否在每个认知行为模式下都存在，只是比例多少的问题？ — by 术子米德@2024年3月14日

🤔☕️🤔☕️🤔 【Q】从知识传递的角度，分析所处团队有哪些低效的行为？ 【A】首先，缺少一门课程，把行为认知相关的显性知识，清晰无误地分享给团队小伙伴，让大家知道，接下去遇到的文档，基本就是清晰（Clear），各种基于PPT、临场发挥不少的分享，基本就是庞杂（Complicated），实际在推进的项目，经常改来改去的需求，基本就是复杂（Complex），发布后的各种问题，基本就是混乱（Chaotic），运行好好的系统忽然故障，基本就是困惑（Disorder）。 其次，大家要明白，不同的行为认知模式下，不可言说知识所占的比例不同，实际经验是，它的占比越来越高，甚至有天赋和灵感的展现，也无需惊讶，更不要羡慕，这是持续经验在肌肉里积累的记忆。 最后，在行为认知规律下行事，别抱怨这没有那不行，负面情绪是最低效的知识传递行为。 — by 术子米德@2024年3月15日

🤔☕️🤔☕️🤔 【Q】软件开发过程里，我缺业务知识多点，还是欠技术知识多点，这真是个问题？ 【.I.】参与到项目里，只听得项目经理大喊到：“就给我抄成竞品的样子”，这时候的我，嗡嗡响，做项目经理真好，不需要知识，不需要脸面，只需要大喊即可。 这，也是我现在所处的真实处境。哪来什么业务知识要理解，有的只是那个功能得存在，至于好不好用另说。 最难过的就是，做不出来，说你技术不行，被客户骂了，更要说你技术差得不行，反正自己早就没脸，也就继续无视脸面存在与否算不算个问题。 — by 术子米德@2024年3月17日

通过代码执行过程来了解软件架构 VS 通过软件架构来了解代码执行过程： 大概每个刚入行的菜鸟都想一头扎进代码，恨不得马上debug起来——不理解架构甚至不理解业务知识，这可认为是最低效行为

1.需求讨论会，产品经理在讲需求的时候，其他人随意打乱话题经常会跑题。 2.线上发现问题经常很多人都去解决问题，有的在看问题，有的在瞎看。 3.经常同类型的问题出现很多次，没有解决方案都是临时解决问题，没有从文本根本去解决。

在收到的需求中,有相当一部分并不是问题本身,而是解决该问题的方案,照着这些方案去做,大概率是要返工的,所以在收到需求或解决方案后,首先是把要解决的问题给识别出来,然后再讨论解决方案,所谓的把问题问对了,离好答案就不远了.

老师，有一个疑问，前面说知识传递最重要是在于思维分享或者说思维进行交流反馈。 而软件交付流程之前，基于对于业务知识的理解(产生知识)，构造一个目标解决方案。这个目标解决方案可以是业务架构愿景或是选定的解决方案(社会化活动)。然后按照目标解决方案将业务知识转化为软件需求(响应) q：想知道这个社会化活动中的交流双方都是什么角色