03|通过知识过程重新理解软件工程
徐昊
![](https://static001.geekbang.org/resource/image/94/92/94cd87e35e1902bc4bc679c14dc33a92.jpg)
你好,我是徐昊,今天我们来继续学习 AI 时代的软件工程。
通过前面的学习,我们知道:
所谓知识过程,就是从知识管理的角度理解我们的工作,将我们的工作看作产生、传递、应用、消费知识的过程;
不可言说的知识是复杂工作中真正发挥作用的知识;
不可言说知识需要从经验中获取,很难通过语言或其他形式传播;
不可言说知识的学习与传递会产生不同的认知行为模式;
不同认知模式具有不同的效率。
那么,我们可以通过知识过程中,产生的不同知识,以及这些知识传递过程中产生的认知行为模式,来理解整个知识过程。通过不同认知行为模式,来理解整个知识过程的效率。
今天我们就将以软件工程为例,将它转化成知识过程,并识别其中的认知行为模式。
软件中包含的知识
软件本身是载体,并不是真正的产品,真正的产品是包含在其中的知识。
在这一点上,软件与书籍是一样的。虽然站在读者的角度看,书籍是产品,但作家真正关心的并不是书,而是其中的人物、情节、故事线。对于非虚构书籍而言,可能是观点、结构、论据等。真正有价值的并不是书,而是书中所蕴含的内容。所以作家可能不会过多地考虑书是如何被印刷出来的,但是要对如何组织其中的内容深思熟虑。对于作家而言,内容才是真正的产品,书籍只是内容的载体。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
![](https://static001.geekbang.org/resource/image/d0/e4/d0880927e2a522a038be2d04bf19dfe4.png)
软件工程的知识过程重新理解,强调软件本身是知识的载体,而非真正的产品。文章指出软件中包含的最重要的知识是业务知识和架构知识。业务知识描述了软件如何帮助客户解决问题,而架构知识则定义了系统中组件的类型和交互方式。除了软件,人和组织也可以成为知识的载体。通过不同认知行为模式,可以理解整个知识过程的效率。因此,将软件的研发过程构造为知识过程,需要围绕这两种知识的提取与传递构造知识过程。软件研发的过程是一个对于业务知识学习的过程,是复杂认知行为模式。进入到交付过程之前,需要将业务知识转化为软件功能需求,这是目标解决方案的应用,是一个不可言说知识应用的过程,是庞杂认知行为模式。架构知识也可以看作是从技术视角出发的解决方案。在软件构造过程中,功能性和非功能性质量保障措施会带来不同的认知行为模式。理解了软件工程中的知识传递,与它们带来的不同认知行为模式,可以评价不同的研发方法带来效率的差别。文章通过对软件工程的知识过程进行重新理解,为读者提供了新的思考角度,帮助他们更好地理解软件工程的本质。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《徐昊 · AI 时代的软件工程》,新⼈⾸单¥98
《徐昊 · AI 时代的软件工程》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(12)
- 最新
- 精选
- 一只豆这一课像是个捧哏,勾的我贼期待下一篇~
编辑回复: 这比喻真酷
2024-03-13归属地:广东 - 临风我们做事情常常希望能找到第一性原理,这样就能认识到事物的上限和边界,也就不会产生妄念,指望通过低效的方法达到高效的结果。我不知道老师将认知模式运用到软件工程算不算真理,是不是软件工程的本质,但我觉得这个理论至少提供了一个很好的思维框架,帮助我们去理解软件工程的本质。 软件工程在我看来就是为了去解决日益增长的软件规模和逐渐复杂的人员分工之间的矛盾,这个矛盾又集中体现在知识传递的过程。也就是我们常常会发现,一个功能需求,其实不是技术实现上有多难,而是因为软件规模过于庞大,以至于个人不能掌握全部的上下文信息,而复杂的分工,又导致开发者很难串联起全流程,站在客户的使用场景,去开发一个完美解决客户问题的软件产品。 认知模式的分类,给了我们一个很好的认识视角。首先,知识传递的效率,很明显是清晰模式 > 庞杂模式 > 复杂模式 > 混乱模式。回到开发场景,清晰模式就像搜索答案,它效率应该是分钟级的;庞杂模式就像一个老手接到需求,他能很快知道要做什么事情,并分析清楚各个业务场景和边界条件,效率是小时级的;而复杂模式就类似一个新手接到需求,完全是懵的,需要不断的问别人,不断的探测,它的效率常常是按天来算的;混乱模式就更别提了,效率基本未知,完全无法预测需要多长时间,甚至花了很多时间都无法认识到问题的原因。 所以软件工程要做什么,就是尽量把复杂模式变为庞杂模式,把庞杂模式变为清晰模式。我猜老师后续就是要回答,AI时代如何升级认知模式,如何让认知效率产生质变,期待后续的内容^-^2024-03-13归属地:广东16
- aoe1. 宁可加班找 Bug,也不愿意学习 TDD 2. 宁可加班堆功能,也不愿多理解一点需求 3. 不仅一次因欠费导致服务无法正常运行,偶尔还是会出现 4. 任职期间疯狂复制粘贴代码,运气好点加班改 Bug,运气不好自己都待不下去了 5. 相信产品说:需求不会变了 6. 使用百度搜索问题,看了很多看起来有道理但就是不能解决问题的回答 7. 不使用 AI 辅助编程,坚持纯手工 8. 盲目追求「微服务」,原来很多简单的事情,变的无比复杂 9. 以为用了 K8S 就能各大云厂商一键部署,结果支付给云厂商的费用更多,稳定性、吞吐性能、服务监控都不如云上已有的服务。 10. 时间紧多找几个人一起实现功能,实现的第一版在预期范围内,后面改来改去,谁改谁害怕2024-03-13归属地:陕西5
- 术子米德🤔☕️🤔☕️🤔 【R】软件=书籍 is 载体,知识=内容 is 产品。 软件知识 = 业务呈现知识 + 技术架构知识。 业务侧学习过程是复杂认知行为模式,从探测(Probe)已知开始,到感应反馈、再响应改进的复杂过程。 技术侧设计过程是庞杂认知行为模式,从感知(Sense)问题开始,到分析解决方案、再响应软件需求的庞杂过程。 【.I.】所需、所能,面对你所需、看看我所能,所需用软件呈现的业务,所能用技术做出的功能和达到的品质。 假设,面对所需,我因不熟悉业务,也因无人已经为目标梳理通所有的业务所需呈现的样子,那么我能做的就是,从接触到部分开始,先做下去,先呈现出个样子来,基于此从已知向未知探测,或基于此修正对所谓已知的误解,我的情绪主调是紧张。此时,有个隐式的假设,那就是我的所能是个超集,它大于当前已知所需、以及探测出来的新所需,它们已经或即将要的所能,我的情绪主调是烦人。 可实际上我发现,我的所能从未如此。所需越是展开,发现所能越是匮乏,情绪里慌张感逐步积累,跨进慌乱感的时刻,往往是发现原来的业务分析,在新的视角下看来,其实都不合理,甚至可以说全是错的。推倒重来,继续糊墙,这就是个问题。 如果在此之前,只有实现代码,那绝无重来的勇气;如果有实现代码、还有验证代码,即所谓TDD的践行者,那么心理上可以推倒,实际无力重来;如今LLM based Coding Assistant上场,说来一起先审阅一下验证用例,再一起加固下验证代码,然后直接删除旧实现代码,由它,AigCoder来没日没夜重写实现,只要符合验证用例,至少会有一份功能一致的新代码,这就是开发新范式的诞生。 【Q】不可言说知识的应用,是否在每个认知行为模式下都存在,只是比例多少的问题? — by 术子米德@2024年3月14日2024-03-15归属地:浙江2
- 术子米德🤔☕️🤔☕️🤔 【Q】从知识传递的角度,分析所处团队有哪些低效的行为? 【A】首先,缺少一门课程,把行为认知相关的显性知识,清晰无误地分享给团队小伙伴,让大家知道,接下去遇到的文档,基本就是清晰(Clear),各种基于PPT、临场发挥不少的分享,基本就是庞杂(Complicated),实际在推进的项目,经常改来改去的需求,基本就是复杂(Complex),发布后的各种问题,基本就是混乱(Chaotic),运行好好的系统忽然故障,基本就是困惑(Disorder)。 其次,大家要明白,不同的行为认知模式下,不可言说知识所占的比例不同,实际经验是,它的占比越来越高,甚至有天赋和灵感的展现,也无需惊讶,更不要羡慕,这是持续经验在肌肉里积累的记忆。 最后,在行为认知规律下行事,别抱怨这没有那不行,负面情绪是最低效的知识传递行为。 — by 术子米德@2024年3月15日2024-03-15归属地:浙江1
- 术子米德🤔☕️🤔☕️🤔 【Q】软件开发过程里,我缺业务知识多点,还是欠技术知识多点,这真是个问题? 【.I.】参与到项目里,只听得项目经理大喊到:“就给我抄成竞品的样子”,这时候的我,嗡嗡响,做项目经理真好,不需要知识,不需要脸面,只需要大喊即可。 这,也是我现在所处的真实处境。哪来什么业务知识要理解,有的只是那个功能得存在,至于好不好用另说。 最难过的就是,做不出来,说你技术不行,被客户骂了,更要说你技术差得不行,反正自己早就没脸,也就继续无视脸面存在与否算不算个问题。 — by 术子米德@2024年3月17日2024-03-17归属地:浙江
- dawei通过代码执行过程来了解软件架构 VS 通过软件架构来了解代码执行过程: 大概每个刚入行的菜鸟都想一头扎进代码,恨不得马上debug起来——不理解架构甚至不理解业务知识,这可认为是最低效行为2024-03-17归属地:浙江
- zyz1.需求讨论会,产品经理在讲需求的时候,其他人随意打乱话题经常会跑题。 2.线上发现问题经常很多人都去解决问题,有的在看问题,有的在瞎看。 3.经常同类型的问题出现很多次,没有解决方案都是临时解决问题,没有从文本根本去解决。2024-03-15归属地:北京
- webmin在收到的需求中,有相当一部分并不是问题本身,而是解决该问题的方案,照着这些方案去做,大概率是要返工的,所以在收到需求或解决方案后,首先是把要解决的问题给识别出来,然后再讨论解决方案,所谓的把问题问对了,离好答案就不远了.2024-03-14归属地:上海
- 起个名称吧老师,有一个疑问,前面说知识传递最重要是在于思维分享或者说思维进行交流反馈。 而软件交付流程之前,基于对于业务知识的理解(产生知识),构造一个目标解决方案。这个目标解决方案可以是业务架构愿景或是选定的解决方案(社会化活动)。然后按照目标解决方案将业务知识转化为软件需求(响应) q:想知道这个社会化活动中的交流双方都是什么角色2024-03-14归属地:陕西
收起评论