18｜兼容性问题：如何有效解决兼容性问题？
陈旭
你好，我是陈旭。
上一讲我们提到，在软件的演进过程中，特别是在低代码平台这样的庞大软件工程中，兼容性问题，也就是破坏性变更是无法避免的。只要软件的代码有改动，就有可能引入破坏性，因此破坏性变更与软件的演进之间如影随形、不可分割。
破坏性变更所造成的后果，有可能微乎其微，也有可能是致命的。会造成严重后果的破坏性变更往往会受到重点“照顾”从而被妥善解决，那些没那么大破坏力的破坏性变更，一旦泄露到线上，不仅会造成体验问题，还有可能造成小范围功能不可用。
这一讲我们就承接上一讲的内容，重点讲讲如何妥善处理兼容性问题。当然，发现破坏性变更是解决它的第一步，具体我已经在上一讲中详细介绍了，所以我建议你在继续这一讲的学习之前，先回顾一下上一讲的内容。在讲具体如何解决之前，我们先来分析下低代码平台中一般会有哪些类型的破坏性变更。
有哪些类型的破坏性变更？
Schema 数据结构的变更是低代码平台演进过程中最常见的破坏性变更。
我们都知道，低代码平台往往会采用结构化的数据来保存开发者在平台上所作的配置，这些配置数据就是 Schema 数据。Schema 的数据结构往往是随着低代码平台的功能迭代同步发生变化的，典型如某个字段一开始只要一个简单值类型就够用，后来扩展为一个包含多个属性的对象以适应日益复杂的功能；又如从一个单值扩展为一个数组，或者反之，从一个数组简化为一个单值；再如多个复杂字段的各个属性的拆分与再组合。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了在软件演进过程中不可避免的兼容性问题，特别是在低代码平台中的应用。作者指出破坏性变更对软件的稳定性和功能造成的影响，详细分析了低代码平台中常见的破坏性变更类型，包括Schema数据结构的变更、模板文件更新以及外部环境或依赖引入的破坏性变更。文章强调了解决兼容性问题的重要性，并提出了一些解决方法和建议。此外，还介绍了使用时间戳和版本号来标记破坏性变更的方法，以及如何通过标记快速找到应用数据中已包含的破坏性变更。作者通过具体案例分析了如何处理不同类型的破坏性变更，包括Schema数据结构的变更和模板文件的更新，以及如何使用处理器来消除这些变更带来的影响。最终，文章提出了将兼容性问题化整为零来处理的方法，为软件开发人员提供了实用的技术指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《说透低代码》，新⼈⾸单¥59
《说透低代码》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
黄骏老师对分布式系统的兼容性问题有研究吗？能推荐一些文章或者论文吗2023-12-19归属地：湖北
mm我们的低代码平台提供一些开放api供外部系统扩展调用，由于数据结构的变化导致传参和返回值会有改动，这和本节讲的正好相反，是相反方向的不兼容，会因为低代码平台的升级导致外部系统受到影响。目前采取的方式是提供新的api，原有的api不动，并且在发布文档告知用户将在未来的XX版本去掉此api。针对此类问题，老师是否有其他更好的建议？2023-02-22归属地：北京
造梦者基本也是数据结构的breakchange导致的错误，我一般的处理方式就是在数据初始化绑定的时候将所有缺失或者不合规的结构统一进行转换，也会在一开始尽量避免同字段的数据结构的变化，有也是新增一个字段，之后新字段的默认值通过旧字段来匹配。好处是不需要版本控制，看哪个值没有按逻辑补上就好了，坏处是旧数据会有一定程度的冗余。2022-11-29归属地：上海
轩爷两种项目生成方案： 1、低代码生成的项目代码构建于低代码平台之上，支持热部署运行； 2、低代码生成的项目代码与低代码平台分离，支持独立运行。 老师是否可考虑对这两种方式，尤其第二种进行一次讲解，谢谢！2022-10-08归属地：北京- 轩爷印象最深的莫过于跑了N年的angular4，要升级到angular8，连依赖包都不支持了，当初也没有一点点随着angular版本更新而更新，以至于最后只能将就用，要再改也是重新开发一套了。 还有就是element plus的版本更新，导致某些样式效果失效，没办法只能手工改一波。 处理器的确是很好的想法，不过处理器的开发和维护需要长期有人坚持，否则一旦放个几年，就是毁灭性打击，尤其是大版本更新。2022-09-07归属地：北京
收起评论