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

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. 合理模块划分，产品定制部分作为一个插件（但放我们这，这些逻辑并不是有具体定义的定制功能块）

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

相关问题¶