• 大家觉得"动态"编程逻辑这种灵活性的合理性有多大?
  • 发布于 1周前
  • 53 热度
    5 评论
  • 烂好人i
  • 0 粉丝 36 篇博客
  •   
在我最近的一份工作中,我注意到我们的代码库中有大量的"动态"逻辑。例如,我们通过动态提取列名来管理具有不同模式的多个 SQLite 文件,而不是为每个模式进行版本控制。基本上,用户查询可以在不同的数据库上执行,而我们并不需要提前知道数据库上有哪些表格/列。这样的优点是我们不需要为每个数据库写新的逻辑,创建这些数据库的团队也不需要与我们(后端)同步,API 可以"直接"透明地访问数据库内容。所以这种策略被认为是"更灵活的"。

然而,我发现这使得理解、测试和编写代码文档变得更加困难。向后兼容性的提供也变得更困难,或者在必要时定制后端的行为也更为复杂。例如,假设我们在数据库上有一个user.full_name列,但 API 必须返回两个分开的字段(first_name和last_name)。现在的情况是,代码被修改以添加大量的if语句(例如:if column_name == "full_name": ...),向后兼容性变得非常困难。

我有一种感觉,所有这些"动态"的代码在理论上听起来很聪明、很酷,但实际上它变成了一个负担。这是一个众所周知的问题,还是我理解错了?我想向我的团队阐述我为什么认为这是一个问题,但我缺乏参考文献。你能提供一些我可以用来分享我的观点的信息吗?这种做法有一个名字吗?有关代码"动态性"的最佳实践是什么?
用户评论
  • Vinda
  • 也分实际场景吧,如果是提供的云数据库的业务,那就是无法提前知道用户会创建什么样的数据结构。 但还要提供 API 去操作数据库。
    如果要针对特定用户的数据表做处理,例如拆分姓名,那就应该让用户自行的创建一个数据前置、后置处理器去处理。
    如果场景中没有这个“用户”,那就应该由业务自行的来抽象一个,哪个是这个“用户”,例如 A 业务、B 业务。

    总结一下:运用领域思维去设计总是无往不利,比如这个场景:总得有人知道数据结构吧? 谁知道谁处理就不会有这种疑问了。
  • 2024/5/9 17:09:00 [ 0 ] [ 0 ] 回复
  • 耀国
  • 从个人项目经验上来看,大多数“动态”xx 的功能是不合理的过度设计,动态的意思是某些逻辑无法在开发时确定,或者需要支持开发好后灵活变更。绝大多数场景,就是单纯的没想好系统模型设计而导致的,除非确实是一个需要支持灵活变化的部分才需要动态话(典型场景是一个动态表单,运营可以灵活配置创建,免开发)。
  • 2024/5/9 16:59:00 [ 0 ] [ 0 ] 回复
  • 春风不醉
  • 不是很懂,除非有工具能自动映射数据库表结构为代码,否则不都是动态查表的吗?不管你是写 SQL 查询还是用了什么高级工具或者流程,最终数据库表字段一改,你查询代码或者 DAO 层就是得跟着变化吧。只是说这个动态的过程是反映在业务代码层,还是反映在数据库中间层部分而已?

    另外如果帖主提到的这种情况,不是落在每一处业务代码中,而是也分层做了隔离呢?那还算动态吗?
  • 2024/5/9 16:51:00 [ 0 ] [ 0 ] 回复
  • Spring
  • 一个最简单的外行指导内行逻辑就是:万物皆可动态 以及 万物皆需封装。前者会让所有本来简单直接的设计变成一个臃肿的怪物。后者会让开发进程无限拉长直至项目失败。
  • 2024/5/9 16:42:00 [ 0 ] [ 0 ] 回复
  • 荒岛初冬
  • 这就是“复杂性不会消失,只会转移”。最佳实践应该就是不要盲目追求灵活性,像数据格式这种东西就应该老老实实约定好固定下来……API 和 DAO 中间还是需要中间层做解耦,不要搞什么 API 的字段直接对应到数据库的飞机。
  • 2024/5/9 16:35:00 [ 0 ] [ 0 ] 回复