二分编译

背景：

在大型项目开发过程中，编译一次可能就需要半个小时甚至更久。

编译失败的时候主要是看报错信息，如果实在找不到报错信息，或者说真的就没有报错信息，而改动点比较多比较分散，如何手动定位出错代码呢？

 

1，修改点划分

我们把修改点按照合理的分类方式和适度的颗粒度，分割为若干修改点。

分割要求是，每个部分的修改都可以成功编译，比如修改了函数入参类型，同名的.c和.h文件就需要被划分到一起。

分割方式包括但不限于：按模块分、按文件分、按pick的commit点分、按函数分、按行分等等。

按pick的commit点分是我现在遇到的情况，我的修改代码是从另外一个分支的MR中pick过来的，有9个commit点，所以我可以分割为9份修改点。

 

2，排查编译

假如修改点一共是9个，那么我们把代码下载9份，然后同时编译这9份代码，如果编译资源足够多，在一次编译时间内，我们就能确定哪个或哪些编译点有问题。

 

3，时间复杂度和空间复杂度

所谓时间复杂度就是几次编译时间，而空间复杂度，指的是编译所占的资源空间，也就是一共编译的次数。

上述的排查编译，时间复杂度O（1），空间复杂度O（n）

 

4，二分编译

如果我们确定或者几乎确定，出错的修改点只有一份，那么我们下载一份代码，只合入一半的修改点，编译一次就知道出错是在哪一半的修改点。继续下去直到找到目标。

时间复杂度O（log n），空间复杂度O（log n）