跳转至

管理多个构建目标的逻辑差异

TODO

如何管理多个目标间逻辑的差异,即custom部分逻辑导致业务代码膨胀的问题。

google git 定制功能

这段描述和我们遇到的问题类似

由于同一个项目需要提供给不同的客户,同时不同的客户又有各自定制的功能。即一个项目,多个不同的定制版本的模式。因此引发了多个版本管理的问题。如果每个定制版本都一份代码,对于代码的维护将会非常困难,因此共用一份代码是必须的。     最开始,由于定制版本不多,差异也不大,所以通过设定一个静态值来表示不同的定制版,再由运行时决定功能逻辑。后来,随着定制版本增多、各版本之间的逻辑差异加大,导致版本判断的代码越来越多,逻辑越来越复杂。由于冗余代码的增加,维护也越来越困难。因此,代码的管理方案也需要相应的改变。首先想到的是通过SVN等版本管理工具进行管理,将基础版本作为主干,各定制版本在分支上开发。在一个分支上添加了公共功能或者是修复了公共功能部分的BUG时,再将代码合并到主干,其它分支再到主干上同步。这是一个优秀的解决方案,但是在公共部分的代码更新频繁的情况下,这个方案会导致频繁的分支同步与合并。虽然在改动量小的时候,及时更新同步可以有效解决合并困难的问题。

作者:宅男9号 链接:https://www.jianshu.com/p/c604c3feaee2 來源:简书 简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

放到具体场景中,一个简单的例子就是: page_main中不同产品(A/B/C)的逻辑不一样:

if (oem_pid == PRODUCT_A) {

}
else if (oem_pid == PRODUCT_B) {

}
else if (...) {
    ...
}

产品多起来后,这些代码就越来越难以维护。

  • 方法1. 在不同分支里管理逻辑差异,但在合并公共特性代码时很难管理,会花费大量人力。
  • 方法2. 类似方法1,提出一个公共特性core的submodule
  • 方法3. 合理模块划分,产品定制部分作为一个插件(但放我们这,这些逻辑并不是有具体定义的定制功能块)

相关问题

大致的思路还是通过工程架构,合理划分模块,隔离

使用git的分支功能实现定制功能摘取与组合的想法 https://www.cnblogs.com/bee0060/p/3487213.html

Git多个分支如何正确的共享代码,并且保持分支独有的代码? https://www.zhihu.com/question/65888370/answer/240089470 https://www.v2ex.com/t/393932