布景

笔者在字节作业，担任小团队的二方库保护与一些技能底座的选型，一直在推动团队中各个项目进行二方库的保护和晋级，这其中也遇到许多阻力。恰好字节的内部论坛上也有一些关于团队内二方库依靠版别过老、不同服务依靠的版别号跨度过长等问题的评论。自己的作业实践与这次评论引发了我的一些思考，我测验以一种相对体系的办法梳理出二方库办理窘境的原因，并测验给出一些处理方案。

先解说一下评论的范围：

何为二方库？

二方库一般指由团队内自己的需求出发，自己开发的一些lib、sdk、framework。既包含事务小团队开发的公共代码，也包含公司等级内开发的公共代码。

在本篇文章中，这是评论的首要对象。

何为三方库？

三方库一般是不由自己团队掌控的代码，比方github上的开源代码。

尽管有些公司等级的公共代码也不由自己团队把握，可是考虑到这种类型的代码库一般有着十分好的保护、便利的oncall渠道，且是一部分人专职的东西（这是要点！），所以我也分类到了二方库里。

针对事务开发同学，在下面的部分评论中并不需求区别二方库与三方库，此刻会以“二/三方库”这种写法加以区别。

写给谁看

由于我恰好既要保护小团队的二方库，又要运用公司范围内的二方库，一同偶尔也会开发一些事务代码，所以我既是事务开发同学，也是二方库开发同学。因而这篇文档一同面向了二方库开发同学和事务开发同学。这有助于两边增进对对方的了解，也能够把整个工作说得愈加全面，可是不免得逻辑有些混乱和杂乱，请谅解。

何为窘境

所谓窘境，就意味着这是一个在比较长时刻内，多方诉求都无法得到满意与平衡，以至于咱们都怨声不断而又无力改动的一个场景。而一眼能够看出，窘境中首要的角色是事务开发同学与二方库开发同学。

二方库开发

二方库开发同学一般会依照roadmap，一同结合各个事务方的功用诉求、功用诉求、bug反馈，不断完善二方库。在这个过程中，二方库开发同学天然会有动力去推动咱们晋级二方库：

  1. 二方库开发同学也背负着KPI、OKR、ROI之类的压力，期望事务开发同学尽快晋级二方库到最新版别，以便在节省XX CPU资源、新功用被XX个团队运用到等目标上体现出自己作业的价值。

  2. 许多对feature与bug的oncall都是基于老版其他，晋级到最新的版别就能削减这些oncall。

  3. 最新版其他问题的oncall更容易处理，版别越老，相关oncall越难处理。

  4. 部分break change的改动能够做兼容，可是需求2-3个版别进行渐进式的晋级。而假如事务方晋级不及时，则这种渐进式的兼容晋级就无法施行。

  5. 假如有v0到v1这种大版别晋级，假如事务方不及时晋级到最新的v1，则二方库开发同学需求一同保护多个大版别。保护压力大。

  6. 巴望自己开发的东西能够上到出产环境中实践运转，完成个人价值。

事务开发

事务开发同学一般会依照排期完结相应feature的开发和bug的修正，而二/三方库的晋级并不在作业范围内。面临二/三方库的晋级，开发同学一般遇到了这些问题：

  1. 事务同学担任feature开发与bug修正，而花时刻研讨二/三方库新版别并晋级并纷歧定能进步开发效率，也与绩效无关。因而不愿意投入时刻去了解二方库新版别。

  2. 二/三方库的晋级成功了也没有肉眼可见的收益，晋级出bug了还要自己担任来修正，对绩效有（潜在的）负面影响。

  3. 看不懂二/三方库的release note，有些乃至没有release note，导致不敢晋级。

  4. 不了解晋级的收益在哪里，不仅仅单次晋级的收益，也包含跟着二/三方库的规划持续晋级的收益。假如二/三方库自己的长时刻规划也没有说清楚，则咱们就没有持续晋级的动力了。

  5. 忧虑二/三方库的最新版别不安稳。有些咱们都依靠的二/三方库的测验也没有那么完善，单测覆盖率并不高（更别提场景覆盖、分支覆盖了）。

  6. 便是不想依靠最新版别，只想依靠相对安稳的次新版别。期望二/三方库自己能够区别试验版别与安稳版别。

晋级真的有收益吗？

从事务开发同学的视点去看，晋级并不能总是真的带来收益。常见的晋级收益有这些：

  1. 二/三方库晋级能带来功用进步

  2. 二/三方库新版别处理了已知的bug

  3. 二/三方库供给了新功用，而且新功用恰好能够支撑事务开发

惋惜的是，当咱们去看一个二/三方库的release note的时分，咱们并不是每次都会得到如上信息。有时分是由于release note没有把工作说清楚，有时分是真的这次晋级和自己没啥关系。

那么，假如咱们晋级没有这些收益，咱们就不晋级了吗？有些二/三方库确实是这样的。可是那些被项目深入依靠的二/三方库会是例外。**被项目深入依靠的二/三方库在没有确定性收益的状况下，也值得定时晋级。**首要解说下什么是“被项目深入依靠的二/三方库”，一般而言，能够称为framework的东西、是事务逻辑的底层二/三方库都是，比方：

  1. go、Java、Python这样的语言版别，以及随版别发布的核心库

  2. kitex、fasthttp、gin这些web server结构

  3. gorm、gen这些ORM结构，以及其底层驱动，比方mysql-driver

  4. 异步任务、作业流结构

  5. go-valid等用于API校验的库

  6. logger、metrics、promonitor之类的和监控有关的库

其次我想用一个比方来论证被项目深入依靠的二/三方库在没有确定性收益的状况下，也值得定时晋级

代码的功用、功用的优化是没有止境的。事务代码是如此，二/三方库的代码也是如此。有时分咱们想完成特定功用，或许做特定优化，便是要依靠新版其他二/三方库（或许依靠二/三方库的生态链东西，而这些生态链东西依靠了新版其他二/三方库）。可是，咱们不能比及有这些需求的时分再做二/三方库的晋级，由于在此刻，服务依靠的版别距离最新的版别现已差太多了，有太多的不兼容改动，晋级的危险被累积和扩大了。就算是把保证兼容性放在生命信条里的golang，也会由于各式各样的原因作出不兼容的改动：

  1. 由于bugfix和安全问题而导致的不兼容。这种状况下二/三方库的保护同学没有办法做兼容。比方golang由于安全问题要修改os/exec的默许履行，这打破了兼容性：go.dev/blog/path-s…

  2. 跟着功用迭代而逐步不兼容，比方golang要用go install来代替go get进行程序装置，go get命令在1.17装置程序时会warning，go get命令在1.18时就无法用于装置程序了。ioutil的抛弃也会阅历类似的过程。

  3. 其他潜在的由于功用迭代或许代码重构导致的不兼容。

而假如咱们不仅仅依靠了二/三方库，还fork下来做了一些魔改，那么工作会愈加糟糕：咱们的修改或许会和最新版别有冲突，而修正冲突又让整个工作费事了一重。

咱们就实践遇到了这样的问题：

咱们运用google的grpc结构，其运用protoc界说API，并运用gateway来兼容http请求。在功用迭代中，咱们需求针对不同的用户回来不同的结构体，一开始咱们用oneof来完成这个功用，即多个结构体都完成一个interface，然后回来恣意一个都能够。可是跟着白名单的变多，有二三个字段都是依据开白的状况动态决定是否回来的，那么2个字段就需求界说4个不同的结构体，3个字段就需求界说8个不同的结构体，这给咱们保护代码带来了巨大的费事。

后来咱们发现最新版其他gateway支撑了字段粒度的可见度界说，能够很好地处理咱们的问题。可是不幸的是，咱们不只落后了最新的版别太多，咱们还魔改了最新的版别。至此，咱们没有人力和能力去做跨如此之长版其他晋级，下面两个困难，光是想想就打退了咱们一切人：

  1. rebase咱们的魔改到最新的版别，而且保证咱们需求的功用、grpc本来的功用都不出错。

  2. 把咱们跨越的版其他release note全都看一遍，看看有没有对咱们不利的影响。

好的，最后咱们放弃了晋级，而且计划和PM商议削减白名单的数量，而现有的需求只能硬着头皮上了。

复盘这个比方，在项目立项之初，谁能想到咱们未来会依据白名单动态决定某个字段是否需求回来呢？（当咱们需求这个功用的时分，距离立项选择grpc现已过去了3年多了）。可是从一个混沌的视点来说，咱们未来需求的功用，他人也会需求，而且或许比咱们更早需求，并完成了，咱们只需求定时晋级，就能够享受到他人的效果。而且我信赖grpc完成的对咱们事务有协助的功用和优化远不止这些。

因而，假如是一个还在频频开发的项目，那么外部依靠的二/三方库或是出于功用、或是出于功用，或是出于生态链东西依靠新版别，总是要晋级依靠的。其中二方库由于和开发诉求贴合更近，更容易频频晋级。那么迟迟不做依靠晋级，比及堆积了满足多的版别才做晋级，晋级天然变成一个很杂乱的工作（长时刻不晋级堆积前史债款）。所以我觉得关于还在频频开发的项目，不做依靠版别晋级是一个没有远见的懒政。

“能用就不要动”

我想特别评论一下“能用就不要动”这个观念。

首要，服务的安稳性依靠的是体系性的dev ops，而不是“不改代码”。关于一个还在演进的项目，修改的数量并不能与危险的大小画等号，指望经过不改代码就能进步服务的安稳性，是一个很荒唐的工作。

有些同学会忧虑晋级SDK会导致服务出bug，从而被追责，影响绩效，我觉得大可不必忧虑。假如一个功用重要，那么必然会有完善的回归测验来覆盖，不必忧虑改代码就会导致严峻毛病。（当然假如没有dev ops那就QAQemmmm……= =!）而小bug本身不是要点（谁家体系里没点bug呢）。另外，只需代码有变更，就或许会导致晋级挂了，那么凭什么二方库的晋级导致的事端，比加新功用导致的事端要罪加一等呢？一般来说，只需不是触发红线导致的事端，都不会追责到个人。

所以咱们看到，进步服务安稳性的关键是体系性的dev ops。假如一个具有旺盛生命力的项目会信奉“能用就不要动”而不晋级依靠，那么阐明这个项目的dev ops必定有比较大的问题，其本身质量也堪忧。不过仍是要限定一下范围，假如在版别晚期，回归测验都快完毕了，那么此刻暂时不晋级依靠，等下个版别再晋级也是合理的。

其次，“看任何准则、理念、办法的时分都不能脱离上下文和适用场景，做教条式的了解”。咱们刚刚评论了什么状况下，不应该“能用就不要动”。那么状况下适用“能用就不要动”呢？

假如是一个现已很少有改动的项目，不晋级就不晋级，问题不大。这类项目一般不仅仅一个二方库的版别落后了，乃至编译器、官方库、所需求的运转环境都或许现已落后了；乃至状况能够更遭：这个项目没有自动化的单元测验和体系测验，也没有CI/CD（或许有一个十分混乱，有了还不如没有的CI/CD体系），乃至没有测验用例！对这种项目的任何改动，在现代的软件开发办法论和要求中，都需求比较大的精力去完善和施行测验。此外，由于这个项目不频频改动了，咱们并不能享受到二方库晋级带来的开发效率进步。

或许，假如是一个现已长时刻没有新代码的项目，而且没有人对代码满足了解，那么“能用就不要动”这个观念也勉强能够成立。

已有的处理方案

在公司的范围内，必定也有看到这些问题，一同给出了一些处理方案。

用户群

常用的二方库都有自己的用户群，群内有评论，也有版别晋级的一些告诉。群公告内也有告诉、教程之类的文档。

二方库管理困境

二方库管理困境

不过看的出来，这种论坛性质的用户群，只能推动有闲有空的同学去了解下二方库的新版别。其更大的效果仍是削减二方库开发同学的oncall压力，供给一个评论的环境与氛围。

发布卡点

关于运用公司内统一基础设施进行发布的服务，在服务发布前都有许多的查看项，其中一项便是依靠库的版别卡点。关于现已抛弃的版别，或许明晰知道有严峻bug的版别，能够阻拦发布。

不过这种卡点也有许多约束：

  1. 一般而言卡点不会很严厉，就算是抛弃的不保护的版别，只需没有严峻的bug，也不会卡点。因而起不到推动晋级的效果。

  2. 只要运用公司统一基础设施进行发布的服务才干被卡点，还有一些ToB事务没运用公司统一发布平台。

  3. 就算卡点到了，事务开发同学也纷歧定会晋级，或许会申请豁免。常见的理由有：

    1. 你这个bug咱们没踩到/不会踩到/没有测验出来，所以不晋级。

    2. 现已是版别晚期了，没有时刻再去晋级版别并再做一轮测验，所以下次必定（下次也纷歧定）

    3. 如何保证二方库的新版别又没有新的bug？（压力又来到了二方库版别开发同学）

自动晋级

公司还开发了自动晋级平台，能够提交mr/pr来更新依靠版别，来简化二方库版别更新。不过这个功用也有局限性。

  1. 假如有任何的break change，那么一般不能由东西自动完结更新。

  2. 就算mr/pr都提了，事务开发同学也纷歧定乐意合入。原因参考上一章节【发布卡点】

没有银弹

好吧，在公司有了这么多处理方案之后，仍是有这么多吐槽，阐明这或许又是一个没有银弹的工作了。咱们来浅浅评论一下或许能够缓解这个问题的一些处理方案吧~

说清楚收益，坦白明晰

这一条是针对二方库开发同学的。事务同学的最首要诉求其实很简单：二方包能够把自己的版别内容讲清楚。因而二方库同学应该在版别办理上下一些功夫。针对版别办理问题，我发现有一些做起来很简单，且能有比较大效果的工作：

  1. 用中文讲清楚每个MR的改动面

对，中文！亲爱的母语！尽管英文看起来很专业，可是在实践中咱们的英文表达能力有限，了解能力也有限，经过mr来声明改动面的效果被大大降低了。

举两个咱们实践中的比方，咱们能够看看英文的表达力有多么贫乏：

英文：fix: choice nil
中文：fix: choice回滚或许意外空指针的问题
英文：feat: lock error
中文：feat: 优化锁异常回来信息，现在能够经过errors.Is来判别锁失利的原因

具体而言，这个工作有许多种做法，比方mr的title改成中文的、mr的description添加中文信息等等，咱们和下一步一同看：

  1. 为每个tag供给详实的变更文档

紧跟着上一步【用中文讲清楚每个MR的改动面】，咱们能够运用一些东西来搜集tag与tag之间的mr的信息，依据这些信息去生成tag的description。咱们既能够运用已有的一些开源东西：

github.com/git-chglog/…

github.com/tj/git-extr…

github.com/hilaily/cmd…

咱们也能够自己写一个小东西，而且这个工作在chatgpt之类的AI东西的协助下，写起来很快。实测根本半响就能够写出来一个根本可用的东西。花个1-2天，就能够一键完结如下作业

1. 打tag
2. 搜集tag与tag之间的mr信息，生成tag description
3. 触发流水线，发送飞书/钉钉/微信告诉
4. 设置版别卡点（假如已有版别卡点东西的话）

下面是咱们完成的效果的展现，只需求在本地运转 mr-chglog –next-tag v0.1.8，然后就会生成release note：

二方库管理困境

发送飞书告诉：

二方库管理困境

版别卡点：

二方库管理困境

  1. 写一个文档，讲清楚二方库的长时刻规划

二方库在发布的时分也不会尽善尽美，必定还有一些演进的空间，或许还会有一些已知的缺点。写一个详实的文档来把二方库的长时刻规划、现有问题、预计的处理时刻讲清楚，不只能削减一些oncall，还能够增进咱们对你的了解，累计信赖，自主晋级。

坚持兼容，堆集信赖

另一方面，有时分事务同学不晋级二方库的版别是出于信赖原因，我常见到这些吐槽：

  1. 前次晋级你们的版别，成果服务出了bug。以后再也不晋级了。

  2. 前次晋级发现了一个逻辑不兼容的改动，你们也没说，成果程序挂了，以后再也不晋级了。

  3. 前次晋级你们的最新版别，就发现一个P0等级的bug，以后再也不晋级了。

  4. ……

针对信赖问题，我觉得只要不断进步代码的质量、进步覆盖率、长时刻坚持保证兼容性、有bug及时认错并周知运用方等等办法来不断获取信赖。而在细节上，有这些小办法能够协助你达成上述目标。

  1. 用单测和注释来记载每一个bug

这个创意来自于偶然间看到的go官方库time库下的一个测验代码：

// golang.org/issue/4622
func TestLocationRace(t *testing.T) {
        ResetLocalOnceForTest() // reset the Once to trigger the race
        c := make(chan string, 1)
        go func() {
                c <- Now().String()
        }()
        _ = Now().String()
        <-c
        Sleep(100 * Millisecond)
        // Back to Los Angeles for subsequent tests:
        ForceUSPacificForTesting()
}

十分矮小明晰，很好用。

  1. 假如有break change，则必定要露出出来

其实咱们没那么怕break change，都是现代化的IDE了，智能全局替换一般来说并不是什么费事事。怕的是你有一个隐形的break change，无人提醒也无人知晓。举个比方：

func max(i, j *int) *int {
    if *i > *j {
        return i
    }
    return j
}

成果下个版别改成了：

func max(i, j *int) *int {
    if *i >= *j {
        return i
    }
    return j
}

一个小小的符号，或许会带来大大的不兼容。这种状况建议直接新写一个函数。关于其他更难做兼容的场景，不如让一切的旧用法在代码编译阶段就报错，确保咱们知晓你的不兼容改动。

  1. MR坚持矮小和专注

为了保证你的release note正确且精准，MR应该尽量坚持矮小和专注。这老生常谈了，可是，咱们总是需求不断地被提醒：）

外科手术式的团队

关于开发同学而言，并不是每一个开发同学都有意愿去晋级二/三方库版其他，免不了不少同学有惰性去依靠老版别。可是站在一个团队、一个项目的视点而言，优质二/三方库的重要性是不言而喻的。有时分替换一个json序列化库就能够带来巨大的功用优化，有时分一个好的二方库能够省去十分多重复编码的时刻，有时分依靠的库的老版别爆出来了安全漏洞有必要要晋级。因而在一个团队内，势必要有一些同学了解二/三方库，能够协助团队做技能选型和底层结构建造。

关于这种团队需求，我的经验是，借鉴外科手术式的研发团队的思路，在团队内部区别出一小批同学来“保护开发东西”（包含IDE、开发插件、二/三方库等等）。这一小批同学也是开发，仅仅他们会分一部分精力去“保护开发东西”，所以不太需求制定特殊的绩效规矩。可是这部分同学需求有比较强的自驱能力或许编程爱好，能自主地去了解二/三方库、在手头有非关键的项目去试用二/三方库、不定时做二/三方库新版其他分享和晋级建议。

无形的压力，有限的人力

咱们假如再回顾一下事务开发与二方库开发同学的诉求，就会发现咱们最首要的诉求便是自己的支付要有对应绩效的体现。假如没有对应的绩效体现，那么非自己责任内的工作就不做。那么和绩效有关的工作应该找谁处理呢？找老板。

关于二方库同学而言，让咱们晋级到最新的版别是有天然驱动力的。老板只需求识别到这部分驱动力，给到对应的人力预留即可。比方去建造版别流水线、每个新功用预留满足的时刻去保证兼容性、测验覆盖即可。

而关于事务开发的老板而言，就相对费事一些了，由浅到深，需求意识到这些工作：

  1. 意识到咱们的作业产出有必要得到认可（物质和心思），包含保护二/三方库。

  2. 认可二/三方库晋级与保护的价值，认可“磨刀不误砍柴工”的软件开发效能准则。

  3. 找到合适的、有自驱力的同学来保护、分享、推行优质的二/三方库。

  4. 树立宽松的开发氛围，严厉的体系的dev ops，进步开发的积极性的一同进步服务安稳性。