硕鼠的博客站

大家好，

欢迎收听老范讲故事的YouTube频道。今天咱们来讲一讲，字节跳动正在辟谣路透社的小作文。我坚决不卖，我也坚决不拆。

5月30号，路透社发了一篇小作文，说字节跳动正在做一件脏活。什么样的脏活呢？将TikTok上面的推荐算法原代码，从字节跳动的代码仓库中进行分离，拆成一个独立的代码仓库。希望以后呢，在美国的TikTok，能够有一套独立的运行库，与中国的抖音拆开。消息来源呢，是某些不愿意透露姓名的消息人士。这个一定要讲清楚啊。

但所谓的这些不愿意透露姓名的消息人士，都是字节跳动的员工。他们是字节内部使用lock（咱们国内叫飞书，国外叫lock）使用这样的工具进行开会的时候，一些与会人员进行的爆料。如果说出姓名来，就肯定被开除了，这不用想。所以呢，人家说我们坚决不说具体是谁啊，但是呢这是确确实实是与会人员，已经收到相关任务的与会人员啊，他们出来爆料的。甚至呢还有一些说没有参加这个会，但是事后看到了相关会议纪要的人，也在向路透社进行核实。也就是说，从多个角度上，证实了这件事情正在发生。

字节跳动呢，就出来辟谣来了。原文是：“路透社今天发表的报道具有误导性，与事实不符。正如我们在法庭文件中所说，该法案要求允许TikTok继续在美国运营的合格资产剥离，根本不可能，在商业上技术上法律上都不可能，当然不是在法律要求的270天时间表上。”大概是这样的一个推特的回复。

但是这个里面呢，大家注意，就跟咱们国内很多官方辟谣一样啊，说你这个事情与事实不完全相符，或者说具有一定的误导性，但是到底哪一部分不相符，没说。所以这个辟谣呢，相当于是披了一个寂寞。

路透社呢，面对字节跳动的辟谣，人家也出来回复说：“我们坚持报道内容属实。”那么这个事情呢，到底未来是什么样的，不好说啊。我们呢，稍微分析一下，就从软件角度上，分析一下这个事行不行。

第一个算法到底能不能剥离？咱们先看一下开源代码仓库。你说我现在想剥了一套出来，这其实挺容易的啊。我们在那边叫 fork，就是分叉意思。什么意思呢？就是我建议新仓库，把原来的仓库的东西全备份一遍。下次呢，我就在这个新仓库里边去修改了。我们在使用开源代码的时候，都是这么干的。因为你不能去改人家原来的仓库，我们都是分叉出来，在里边调整。那你说这玩意多简单啊，怎么叫脏活呢？脏活按道理说，就是一行一行离清代码的叫脏活啊。待会我们再讲，“脏活”这个词在这一次的活动中，并不是那么贴切。

那你说既然这么简单，你就可以分叉一个，就可以干活了。呃，那咱就分，不就完事了吗？但是要注意，现在抖音和 TikTok 上用的这些推荐算法的代码，它们属于啊，快速更新和迭代中正在用的代码。这种代码呢，跟开源代码仓库本质上是不一样的。差别在什么地方？开源代码仓库，或者说，一个相对比较好的开源代码仓库，它有一些特性。这个特性是什么？就是它相对独立，它是一个单独的仓库。然后第二呢，它的边界很清晰，我需要调用其他东西，需要依赖其他的仓库的时候，我会把它写的很明白。第三个呢，就是它会有清晰完善的文档，说我们应该如何去使用，如何部署，甚至还有很多会去写一堆 how to，就是当你要做什么事的时候，该怎么办。然后呢，还会有一个比较活跃的社区，一帮人在上面使用这个代码仓库，你哪不会用了，还可以到社区里去问人，还有一帮人坐在这。维护整个的代码仓库。这是一个比较好的开源代码仓库啊，当然也有那种烂的，这个咱就不管他了。而这种快速更新迭代的工程仓库跟刚才我们讲的好的开源代码仓库是完完全全相反的。

刚才我们讲的所有的这些属性，它通通都没有，而且完全是反义词。那么工程库一般是什么样的呢？它通常是一大堆——一定要用这个词，叫一大堆代码仓库——融合在一起的。而且这些代码仓库相互之间依赖，而且依赖的关系相当混乱。代码仓库之间有大量的接口定义、协议规范和版本依赖的关系，就是错综复杂啊。这个是正常工程用的代码仓库是这样。而且它不是一个单独的库，一般开源库是单独库，就算是你有一堆库，他也会有一个相对来说比较完善的描述文件，你可以搞清楚它们之间到底是一个什么样的关系。

正在跑的工程库，如果直接快照所有模块停止更新，直接按照现在的版本分叉，是不是可以啊？对吧，在我们做软件备份，在做很多的软件分叉的时候，呃，我们可以干这样的一个事啊，说哎，现在所有人都停下手里动动作啊，不许更新了，我们就按现在这个时间点，咔嚓把它翻过去，行不行？这事其实也不行啊，为什么呢？因为我们讲到软件测试里边，专门有一个子项目叫什么呢，叫代码覆盖率测试。这事干嘛呢？就是我把整个的软件测试跑完，然后确定说，现在是不是所有的软件代码都被跑到了啊，或者跑到了百分之多少，我们会去做这样的测试啊。为什么要讲这个呢？因为如果现在我就把抖音和TikTok的代码咔嚓停下来，通通都不允许更新了，然后把它搬出一个新的版本来，那么在这个里边，真正能够跑的代码可能只占其中的非常小一部分啊。为什么呢？你说这个抖音不是没出毛病吗？也没贪啊。对啊，TikTok也在那工作呢，那为什么说真正能够跑的代码只占很小一部分呢？

有大量的代码平时是不用的，只有在一些特殊情况下才工作。这就是刚才我们讲那个代码覆盖率测试的时候，我们要尽可能多的把这些代码都跑遍。但是你如果咔嚓停下来，就直接翻过去，就是现在我们能够保证他继续跑的这个代码，只占所有代码上的很少一部分。那么当一些特殊情况发生的时候，而且这些特殊情况未必概率很小，当这些情况发生的时候呢，你就会遇到一些你没有经过测试的这些代码就有可能出错，出了错以后你连找都没地找去，非常麻烦。

那么现在到底在干什么？现在呢，肯定是在进行代码质量梳理。咱们先不说是不是分拆的事情，大企业每过一段时间都会干这个事，就是把这个工程文件，过一段时间要梳理一下，也不能让他这么一直乱下去啊。一乱下去以后，时间长了，你就没法再往前维护，没法往前做了。那么做到一些什么呢？就是将各个模块之间的依赖关系梳理清楚。

你像我刚才讲的这个模块依赖关系到底是什么啊？比如说吧，我今天有一个模块呢，叫做用户认证，就是你上来要登录，这是一个标准模块。然后呢，有另外一个模块呢，叫做付费，比如你要买东西了，你要打赏了，你要付费对吧，这么这是两个模块。那这两个模块一定是单独做的，单独的去更新，单独维护版本。那么在这个过程中呢，他就会说哎，我这个付费模块啊，我要依赖这个用户登录模块。如果用户不登录，你就没法去记录他的支付模式，也没法给他扣。所以必须两个模块是相互依赖的。那怎么依赖呢？一般情况下是这么写啊，说我现在付费模块啊，是3.2.5版，那么这3.2.5版付费模块是依赖比如说10.8点几版的一个登录模块啊，他是这样去依赖上去的。等这个登录模块再去更新和升级的时候啊，他会去要求说哎，你是不是测试一下，我现在更新了，提供了一些新的功能，这些新的功能你是不是要去使用一下。那么，再去开发新的支付模块时，他就会说：“哎，我现在再去更新我的支付模块了，然后我再去要用新的版本。这个新的支付模块你要去依赖，旧版本就依赖不了了。”所以呢，它是相当错综复杂的，这样的一个依赖关系。

你像抖音整个的系统包里，有几百上千个包，都是合理的。那么这些包之间相互依赖，这个版本是版本3依赖版本2，这个版本2的版本可能再去依赖一个什么。而且他们之间有时候会相互依赖，就是他没准转一圈转回来了，A依赖B，B依赖C，C依赖A，他又会有时候会这样转。

那么在这个过程中呢，你就要去进行梳理了。你最后要把他们尽可能的梳理的比较清晰一些，甚至可能有一些代码需要进行重构。这个呢，都是需要进行这样的代码梳理。

那你说梳理就梳理吧，你为什么要把它重新备份出一份来呢？啊，这个其实也很简单，没有人可以在工作环境上干这种事情。啊，什么叫工作环境？就是这边我这刷抖音正给我算呢，对吧，你不能在这个库上去干活，你一定是要把它拆出一份来，在外边干。干完了以后呢，哎，说OK，我们外边这个测试成功了，然后再逐渐的替换回去。那一定是这么干的啊，所以必然是会去做分离的。

那你说我们就把它理清楚，不就完事了吗？啊，其实不是这样的。每一个模块的版本其实分很多版。那当然了，12345是不是算很多版？不是这么算的啊。就是我们在版本里头分成什么呢？比如说啊，日常更新的版本，我开发用的版本，我今天更新了两行，代表明天新写了一个文件，这种版本啊，是不影响其他人的啊，因为这版本就我用啊，其他人都不用。然后再往后呢，啊会有这种叫夜间版。什么叫夜间版呢？你说这个软件开发，白天呢跟晚上不一样吗？是这样的啊，呃我们白天上班啊，晚上呢经常会干这样的一个事情。会让一个脚本自动的把代码抓出来，然后进行编译，进行测试。那么这个版本呢，一般叫夜间版。这种版本呢，有的时候是可以正常工作的，对于小的系统来说可以，但是对于大的系统来说呢，它可能在一定范围内可以用，但是一般情况下，不会进入到生产环境里头去。这个就是夜间版。

再往后是什么呢？就是正式的这种叫做release的版本，就是我们这要发行版。这种版本呢，就是你可以到生产系统里边去用了。但是呢，这种版本啊，也不一定会维护多长时间。虽然我现在发行了一个版本出来，但是可能过两天我又更新了新的，那么我就把这版本废掉了，我就不用再去维护这个旧的发行版了。很多的系统是这么干的。

在发行版之上还有一种版本呢，叫LTS版。LTS版是什么？叫长期维护版本。就是我虽然后边还在不停的发新版本，甚至有新的发行版已经开始发行了，但是呢，我中间那个LTS版本，这种长期维护版本，我还是会维护和更新的。

那你像抖音这么大的一个系统来说，咱们还是以这个支付系统为案例，虽然现在有新的版本又去更新了，有新的发行版出来了，但是呢，我现在使用长期维护版本，我遇到问题你还得给我解决啊，你不能说我就不管了啊。那么他是这样来工作的啊。

所以各个系统包之间的版本，需要进行这样的管理。现在我们把它拆出来了，就是让所有的大的模块，这些系统包，都达到一个至少release的版本啊。说，现在正是以这个版本为基础去工作的。你如果不是依赖的release版本，请通通都依赖到release版本啊。如果有依赖的旧的release版本啊，通通依赖到最新的release版本。可能最新的版本里头多两个函数，这个函数里多一个参数，少一个参数，或者有些哪些功能废掉了。那么，你在这个过程中，你要改代码啊，你要让它能够适应所有的稳定版本。按道理说，大家不应该这么干嘛，但是你想，公司这么大，对吧，而且字节跳动又是以加班多、软件迭代快著称的。萝卜结，不起泥嘛。所以他们原来可能就会啊，代码工程质量上就会差那么一点点啊。现在就要去做这个事情啊。

如果你说，我这个实在是更新的没有那么频繁，那么我们就去依赖这种长期维护版本，那也是可以的。就是需要进行版本梳理，以及依赖关系梳理。那么为什么要干这个事呢？其实也很简单啊，就是你要提高代码质量，或者叫提高代码的工程质量啊，否则的话，你再往后去做这个活，你就没法做了。他这个线就会越接越乱。每过一段时间，特别大的公司都会干这个事啊。

那么，是不是在为分拆提供可能性呢？咱们刚才都是讲软件工程了。TikTok分拆的时候，是不是要先做这个准备？这个可能性是存在的啊，只能这么讲，可能性存在，但你说这就是在做分拆准备，那么就像这些字节跳动辟谣那样说的啊，与事实不符，带有明显的误导性啊。咱不能乱说，那这个事呢，其实也不能算脏活啊，因为大家都干这个，你是必须定期干的，你谁也跑不了这事，这个不能算脏活。

一般在软件公社里是指什么呢？就是吃力不讨好，非常费劲。你真的把所有代码都厘清一遍，其实你有的功夫还不如写个轻的呢，所以这个叫脏活。但是呢，像刚才我们讲的这个过程，其实不算脏活啊，他算是一个正常工作。那么，到底他在干一个什么事情，或者说这一次，他到底是怎么做这个事的呢？

第一个是分叉，就是我们还是要把这个代码分拆出来，尽可能的按照稳定的版本，不是按照当前运行的版本，可能是按照最后一个，各个大模块之间的稳定版本，把它们分拆出来。那么分拆出来以后啊，他们还是要进行新的梳理和调试了。对吧，你有可能你分拆出来的某一个模块的稳定版本，他依赖的那个版本可能不在这个里头，或者是一个旧的。那你在这个时候就要去调代码去了，然后进行接口的梳理，测试用力的梳理。我通常会写一个测试用力，你把测试用力跑通了，就说明这个代码模块是可以用的啊。那么在这一块呢，可能原来不是很完整，现在就要去补充完整，进行代码的版本整理，进行配置的脚本化。

什么叫配置脚本化？这个其实也是我们软件开发里头常用的一个词。比如说吧，我们规定了从现在开始再往后开发，登陆模块应该依赖哪个版本，它的代码仓库在什么地方。你可以怎么办呢？你可以给人上课啊，说我来教一下你啊，你学习一下，或者我写一文档啊，或者呢我整个大模型，你去问他说哎，我现在要掉登录模块了，我应该用哪个版本啊，他送给你生日代码啊。这个呢其实都挺麻烦的啊。像我们原来做软件开发的时候，怎么办呢，就是叫脚本化。我现在需要调用中共模块了，然后自动执行一个脚本，把相关的这种依赖的给我搞退，这个是一般做软件工程，或者大型工程里头比较常用的一个手段啊。这就是现在在干的事情。

那么，自己到底有没有在为分拆做准备呢？这件事必然有，不可能没有。那你说他不是已经表明决心了吗，说我坚决不拆，打死不拆，死门也拆不掉吗？啊，但是最终决定这个事情如何走向的，其实并不是自己跳动，而是两国政府。他呢肯定是叫一颗红心，多手准备。我现在先把这个不能拆这件事喊出来，然后呢，那边我们在不停的跟美国人去商量说，哎你看我到底弄成什么样，你就算我过关，然后也跟中国人那边商量说，你看我这样行不行，那样行不行。他总是会在这个里面去寻找。说到底，怎么样？可以而且呢，这种诉讼也在这坐着。国内，我相信政府关系他们也在做这中美两边的这种外交关系，可能也在每天都在发生变化。那么在这样的情况下，他一定是要做好准备的。你别回过两天说哎，我们谈好了，你拆吧，那他这玩意他咋拆啊？总还是要做一个准备的嘛。

那么分拆算法之后，他算不算就可以拆了呢？这个事呢，其实是一个灰色地带。像我把这个算法拷贝了一遍，那算不算是中国算法？因为中国的推荐算法，是在出口管制名单上的啊，咱不能随便出口这个。中国的推荐算法里头也不能有中国的数据。按道理说，你如果是比较严格的考核的话，把这个代码分叉了一遍，一模一样的克隆了一遍，他就不算是中国人的产品了吗？这不胡说八道吗？咱不能搞这个啊。人家一开源，我们就自主创新，自主知识产权，这一套还是接的time。所以这件事情呢，呃，并不能说克隆了一遍就可以分拆了啊，这个是没有必然联系的。

但是呢，你也要看国内愿不愿意装傻，因为毕竟咱们有这么多案例吗，拿人家的开源代码回来以后，自主知识产权这事干的挺多的。比如说我们拆了，拆完了以后呢，我们对这个事情进行了修改，进行了重写。如果国内愿意认，没准这个也能过关啊。但是这个呢，从呃底层逻辑上说，他是走不通的。但是呃从政府操作上来说，那就是另外一个概念了。

那么接口梳理清楚之后，是不是可以再开发来替代这些算法呢？有很多人说哎，他们把这个接口梳理清楚了，我重新写一个推荐算法在里头，这样他不就行了吗？如果中国政府想去睁一只眼，闭一只眼的话，那他肯定是要找这个借口的。但是要跟他来讲啊，很没有人这么干这个事情啊。从正常软件开发的角度上来说，绝不会有人这么干。为什么呢？你说我把这分好了啊，这就是推荐算法的一个模块，这么多接口，然后两边都不动，我就把中间这块，这个代码换掉，不就完事了吗？啊，这个原因呢，其实很简单，就是软件架构啊，不是设计出来的。很多人都觉得软件不是有架构师吗，你们天天设计架构，那软件架构不是设计出来的，是怎么来的呢？

软件架构啊，是长时间沉淀下来的。今天我需要这个，明天我需要那个，后天我发现这里有一个bug，再后天我又发现了那个地方有一个接口要接。在这个过程中，软件是不断的应对这些需求，然后进行生长。生长了以后，他们会沉淀下来一个软件架构。

并不是说大家就野蛮生长，他也会有一定的规划。但是规划性跟这种随着时间野蛮生长，他是矛盾的两面。就是两面，他都在往前涨。如果有机会重做，绝对不会背着这样的一个包袱。这种随着时间生长出来的软件架构，一定是包袱，一定是说干脆把它扔掉，再来一次。

这跟马斯克现在推特里干的活，是一样的。那么结论是什么，这个事情到底是一个什么样的事情？字节肯定是在进行代码梳理工作，里面有人出来说，我们去爆料了。路透社也得到了相关的这种爆料，他们呢，也愿意用路透社的名声来确保说，这个爆料是靠谱的。那么我们相信这个工作确实在做，然后为分拆做准备，这件事情也在做。

万一哪天，他这个条件确认了，或者说在中美双方的法律框架范围内，哪天让他找到了一个漏洞，或者说双方在进行了一定的摩擦和协调之后，啊留了他一条路，让他生存下去，那么他也要提前做准备。如果说让你去拆了，结果你发现哎，从来没有做过任何准备的话，你到时候拆不开，这事是不行的。但是呢，嘴是不能松的，因为毕竟这么多员工在中国，一个项目也是从中国发展起来的，这么多资产也都在中国，所以呢，一定要去辟谣，说啊你这个，带有误导性，与事实不符，我们卖不掉啊，拆不了一定要讲。这个事情最后的决定权还是交给政府。但是呢，他现在已经干了一个事，这件事叫什么呢？那台阶给您找好了，剩下的您看怎么办吧。啊，台阶是什么？就是我已经把代码分拆开了。哎，如果您愿意睁一只眼闭一只眼，这个台阶在这了啊。这就是这一次字节跳动进行代码分拆整理的一个故事。

好，这期就讲到这里，感谢大家收听。请帮忙点赞点小铃铛，参加disco讨论群。欢迎有兴趣、有能力的朋友加入我们的付费频道。再见。\n