03｜以降低认知负载为前提：为什么遗留系统这么难搞？
怎样理解认知负载？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
遗留系统现代化的重要原则是以降低认知负载为前提。文章通过实际案例引出认知负载的概念，详细解释了内在认知负载、外在认知负载和相关认知负载，并强调了在软件开发中要减少外在认知负载，增加相关认知负载。作者分析了架构不合理、DevOps工具不好用以及系统知识匮乏对外在认知负载的影响，并指出了一些实践可以长远降低外在认知负载。文章深入浅出地阐述了认知负载对遗留系统现代化的重要性，为读者提供了有益的技术思考和指导。文章强调了降低外在认知负载的重要性，以及如何在遗留系统现代化中应用这一原则。通过举例说明了代码重构、架构拆分、持续集成流水线优化等措施如何降低认知负载。最后，文章提出了两个开放式的思考问题，引导读者思考项目中的分支策略以及实践中降低和增加外在认知负载的情况。整体而言，本文强调了降低外在认知负载对于遗留系统现代化的重要性，并提供了相关实践和思考问题，对于从事遗留系统现代化工作的读者具有一定的指导意义。
《遗留系统现代化实战》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
李威置顶1、我们日常是所有人均在develop分支上进行开发，开发完成后，将develop分支代码发布到测试服进行测试； 2、测试通过后，再把develop分支合入master分支，并发布到预发布环境进行测试验收； 3、产品经理进行验收测试通过后，将master分支的代码发布到生产环境； 4、如果在develop分支上进行开发的过程中，有一些线上bug要修复，或者老板们加塞一些紧急的小需求时，就先保存develop分支的代码，然后切到master分支上，并基于master分支拉出一个专门的分支用于修复bug或加塞紧急需求； 5、基于这个专门的分支进行开发测试验收通过后，就将此专门的分支合入develop以及master分支，然后基于master分支进行发布，最后切回develop分支继续之前的开发工作，并删除临时创建的那个分支。 以上，就是我们当前的分支开发模式，我也搞不清楚到底应该叫么子分支模式。烦的就是常常在develop分支上干得好好的，时不时就来个加塞需求，老是要在各种分支间切来切去，恼人的很，有时候不小心没看清楚当前处于哪个分支，结果有时候还得重搞一遍。 针对我们当前这种分支开发方式，不知道姚老师能否提供一些改善建议，感谢。作者回复: 我理解你说的develop应该就是每个开发人员在开发需求时，从master分支上来出来的个人开发分支吧？这个实际上就是feature branch模式。这种模式其实是有一些问题的，比如你的代码是没法持续push/merge的，只能等开发完成后才merge全部代码，没有办法做到真正的持续集成，同时对重构也不友好，因为merge的频率太低了，重构会导致大量的冲突。 而且如你所说的，各个分支切来切去，还要想着向各个环境去merge代码，开发人员除了开发需求外，脑子里还得想着各种跟开发需求无关的东西，大大提高了认知负载。 更理想的分支策略当然是主干开发，但这也是有一定门槛的，国内真正能实施主干开发的项目也并不多，一方面对于人员能力要求比较高，另一方面对需求管理的要求也比较高，尽量不要让需求临时中止开发。但这些都属于内在认知负载，一旦掌握就一劳永逸。而不像内在认知负载那样，需要时刻想着这个想着那个。主干开发还可以解决多分支切换的问题，因为你的代码始终是可以merge的，你可以把手头的代码merge完之后继续在主干上修复bug。 所以我建议你根据自己项目的实际情况进行改善，比如是否可以将比较稳定的需求（或者一个团队内部）建立一个公共分支，某种程度上可以作为你们的主干，可以解决合并冲突和不敢重构的问题。 分支策略是个讨论不完的话题，我甚至觉得光这个就能写一个专栏了……
2022-04-157
aoe睡5秒真是魔幻啊！编辑回复: 笑中带泪……
2022-04-1555
Kent目前实践下来我比较倾向于这样一种方式： master / dev / test / prev / release 基于每个需求ID，开发人员各自从master切出新分支"开发人员名字_需求ID" 开发时，需要集成自测时可自由合并到dev 确定需求完成提交测试时，需要由主管codereview再合并需求分支到test，prev类似 测试产品验收通过的需求，即可合并到master 迭代到期，master合并到release进行发布 --- 这样的好处是：master在任意时间点都保证是生产环境可用的代码，随时可以发布，迭代到期有需求没开发完也不担心影响其他需求发布 目前存在的问题是：项目初期遇到开发人员需求相互依赖的情况，需要特别备注清楚，被依赖需求需要先测试完毕合并到master作者回复: 感谢分享
2022-05-082
子夜枯灯目前工作的系统是ssm得单体架构，供应商提供的。经过了各种魔改，现在项目代码800m。动任何一个地方都要大量人力测试。作者回复: 感谢分享。
2022-04-26- Geek_a10fcf已学习
编辑回复: 编辑回复，快把学后收获交出来～
2022-04-24 
故事、自己写Rap嗨起来作者回复: 😀
2022-04-19
Geeker分支开发，分支发布 master、dev、st、uat、bugfix作者回复: 嗯，这种可以算是国内非常常见的分支策略了
2022-04-17
killer留系统最大的认知负载其实是无处可寻的业务知识。很赞同，其他的都好解决。但是怎么确保业务知识可寻？我们的现状：只要能大致测试通过，就会上线，而没有精力去偿还欠下的债务、改善外在认知负载。如此恶性循环，导致遗留系统的外在认知负载越来越高，修改起来越来越难，新人不易接手。作者回复: 确实在遗留系统中大家都是这么做的，而如果一个新系统不注意这些，也会很快变为遗留系统
2022-04-162
拉欧之前处理一个工作流代码，会在线上环境时不时的出bug; 我分析了一下午发现，原作者在构建工作流的时候用了clone方法，但是没搞清楚深拷贝和浅拷贝的区别，导致所有的工作流用的是同一个引用，只是在多线程下会时不时的更新其中的对象。。 我直接删掉了这个clone，改成new一个新对象，世界清静了 有一种把一坨积累了3天的粑粑排泄出去的清爽感2022-05-212
DCChan第一次听语音，rapper起来了2022-05-131
