【 以下文字转载自 SoftEng 讨论区 】
发信人: darkk (darkk体国经野 义尚光大), 信区: SoftEng
标  题: 【高端】项目规模度量和合并模式研究
发信站: 水木社区 (Thu Apr 22 11:29:42 2021), 站内

1。从标识符看规模
===============

** 1. 相关原始文件

linux内核官方网站 https://www.kernel.org/

我们下载分析的版本是 5.11.15 即
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.15.tar.xz

** 2.逻辑假定、工具及引用数据

三个假定：

① 假定C语言中的“标识符”，尤其是标识符的定义，是软件发挥作用的主要矛盾方面。标识符的数量直接决定系统的复杂性、精细度、语义的丰富，等等。进而，

② 通过统计“标识符”的数量，就可以大致地直观地反应一个项目的发展程度和发展水平。

③ 贡献到一个项目的开发成本是一个整体，但可以通过人均尺度，反应并且代表每个人的一般情况。

这三个假定可能都是有问题的，这可能影响本文说服力的有限性。

工具：

一个自己编写的小脚本。这个小脚本会统计文件中左括号("(")左侧的字符串，并且将其认为是标识符。这些字符串应该只由连续的下划线、小写字母、大写字母、或者数字组成，而且首字母不能是数字或大写字母。这些是认为的标识符：

cx88_audio_finidev
_ARM_V7S_IDX_MASK


这主要是排除常量，主要是统计“函数”和“宏”。

引用数据：

一个网站上的数据 https://thenewstack.io/contributes-linux-kernel/

14,000 个个体开发者和 1,300 个公司给linux内核贡献源代码。

** 3.初步统计结果

使用工具分析可以得到，linux内核有 587346 个标识符。


** 4.数据和分析

（1） 直观了解

1。2005年开始有14000个个人开发者和1300个公司……每个参与了的人平均维护42个标识符，每个公司平均维护451.5个标识符。

2。这个统计不太精准，但是当项目很大的时候应该差不多主要就是标识符了……

3。以下划线 __ 开头的标识符已经很多，已经有 17773 个。约占 3% ，差不多是 1/33 。绝大多数都是双下划线打头的，有 13884 个，单下划线打头的有 3889 个。例如：

_AC
_ALIGN_UP
__zstd_exit

4。以小写字母打头的标识符，绝大多数是通过 _ 连接起来的多个字母串。其中，第一个字母很多是缩写，也有动词，也有硬件的某个代号，等等。例如：

adxrs290_write_raw
dummycon_clear
pch_i2c_remove
xbc_parse_array
zorro_seq_show
zytronic_read_data

等等。

5。从信息量的角度来说，假设每个标识符顶一部网络小说里面的21个字，整个源码差不多一部1233.43万字的网络小说。这些标识符一行一个打到一个网页上，在我的电脑形成了9984880个像素的网页"高度"。。。假设每秒滚屏8400个像素(百度首页的百度logo差不多130个像素，即每秒滚过64.6个百度的标识)，差不多滚20分钟可以把这个网页滚完了。



（文章很长，可看配图）

2.两种合并模式的对比
===================

** 1.合并的一般概念

合并的定义：代码成品正式成为发布成品的部分的环节。



（文章很长，可看配图）

合并和验收的区别：合并强调软件的物理组装和合成，验收一般指工程交付的质量保证过程。

合并和发布的区别：合并强调形成最终产品，发布指成品向交付对象转移。

合并和打字的区别：合并的时候产生的冲突可能也需要通过打字解决，但主要的难度在思维方面；打字指通过手部运动进行信息输入的过程，涉及到的思维活动不一定是代码合并。

合并和构建的区别：合并一般基于已经形成的对象再形成一个更大的对象，有多个来源对象，这个更大的对象来源于这些来源对象，而且合并的过程可能发生修改行为，属于比较微观的具体的工具性的操作方式；构建可以泛指一切某种事物的从无到有的被创造，除了合并，还有许多的操作方式可以构建事物，例如演化，属于比较对象化的宏观实践。

** 2.两种合并模式

假设这580000多个标识符，以42个标识符组成了一个"工作单元"，那么就有差不多13810个工作单元，考虑这些工作单元一开始都在一个人手上，然后他可以分派给3个人(可能包括他自己)，那么一直要分派8.6次，才会变成一个人只有一个工作单元。

这样子，就会形成一个共有8个管理科层，每层都有3个管理下级的软件工程团队和软件开发制度。（这个管理制度主要是假设。）



（文章很长，可看配图）

现在，我们考虑两种合并模式，一种模式我们称为“主动委托，协商合并”。根据这种合并模式，一个变动首先高层次的管理科层产生，然后通过逐级的协商，最后落实到一个开发者手上。等到这个开发者完成了相应的代码交付的变动，然后通过管理科层又逐级合并，最后成为代码成品的一部分。

注意到，这个时候，需求的规模是多大，是不会影响我们抽象理解上的时间的，因为每个开发者和每个管理科层基本上是并行的。由于开发是并行的，即使是某个标识符要改动，或者多个标识符要改动，他们也仍然是从高层向底层扩散，然后底层再向上提交。

我们考虑，为了简化问题，假设开发者的效率是极高的、均质的跟改动的数量无关。时间主要花费在不同的科层的沟通协调上。而且我们假设不同的管理科层的沟通是顺畅的，那么从高层向较低层委托改动，以及较低层向高层要求合并，沟通的时间是一样的，而且也是均质的、跟改动的数量无关。

由于不同的人是同时工作的，所以这一次改动的时间 t 大致上就是(科层树的树高-1)×平均沟通时间×2+开发者开发需要的时间。×2是因为高层的委托需要一次沟通，在开发完成之后的合并，又需要一次沟通，所以每次改动需要两次沟通。那么：

t = 2 * (H - 1) * t_m + t_d

另一种合并模式我们称为“主动提交，被动合并”，这其实也是linux的重要的合并模式。

在“主动提交，被动合并”中，高层级的管理科层并不直接向下委托改动，相反的，他们靠的是较低层级的主动的提交。当有人提交了，较高层级的管理科层，全权决定是否合并到项目中，并且向更高级的管理科层提出合并要求。最后，代码合并到项目的成品代码之中。

我们仍然保持“主动委托，协商合并”的主要假设，但注意到，由于没有委托的过程，所以并没有委托带来的沟通时间。而协商的工作，实际上在被动合并的过程中，由高层级的管理科层决定、主导和完成了。

这样子，我们发现，在“主动提交，被动合并”的合并模式中，合并的用时是：

t = (H - 1) * t_m + t_d

这比“主动委托，协商合并”少了一整个 (H - 1) * t_m 的沟通时间，也即沟通上省了一半。

换而言之，假如一次沟通记为1，在一个有580000多个标识符的项目中，采取“主动委托，协商合并”，一次代码改动将需要 8.6 * 2 = 17.2 次的沟通，而采取 “主动提交，被动合并” ，这个沟通的时间只有一半即 8.6 约等于管理科层的科层树高度。



（文章很长，可看配图）

** 3. 回到现实

我们看到，在两种不同的合并模式，即“主动委托，协商合并”和 “主动提交，被动合并”而言，他们的差别不仅仅是谁的责任更多，谁的责任更少，或者谁负责干什么的，谁不干什么之类的问题。作为一个整体，他们对项目的最终开发效率是有着质的差别的。

当然，在现实的开发过程中，一般也不会有如这里演示的这么规则化的开发实践，但这里已经在一定程度上说明了，开源的意义不仅仅是分享或者开放，在组织行为和工程效率的意义上，开源有其独特的实践路径和特有经验。

从开源社区的实践来看，这些方式可能有助于提高主动提交：

（1） 欢迎他人的提交，而不是怀疑他人的提交、仇视他人的提交。
（2） 高质量的原型，高质量的软件产品，而且要让潜在的提交者知道。
（3） 明确的、稳定的可以动手的提交的指示，让每个潜在的提交者和开发者看到就知道自己可以提交进来，并且迅速走上流程。
（4） 清晰的良好的路线、理念、治理规则的公示，让每个潜在的提交者不用再犯错误，而是愉快地找到方向、完成劳动、实现提交代码。
（5） 肯定提交者的工作。
（6） 善于处理质量和内容的矛盾。

总而言之，软件的劳动成果需要有人维护，松散的开发者也需要联合起来，灵活使用合并权，智慧地提升合并模式，即使不能打造另外一个影响广泛的软件作品，可能也有利于在某种具体的领域、某种特定的场景、某种有着相似需求的软件应用程序的诞生和可持续的发展，甚至带来经济效益和环境社会文化效益。


3。对于创新的启示
================

软件开发过程的沟通环节，是极其重要的环节，正是通过沟通的环节，以具体的开发为生产力的实现主体的开发过程，能够形成为统一的、集中的、有方向的、融合的过程，并且具体地将解决了的问题汇集起来，进而形成了新的版本和新的优势。

软件开发的独特性——识别、理解、转换人的需求为具体的软件开发行为——是一种复杂的思维活动，这种思维活动既有技术性的，又有问题性的，进而是服务性的。采取“主动委托，协商合并”和 “主动提交，被动合并”，具体的开发过程可能会带来不同的具体的开发时间，由于 “主动提交，被动合并”节省了向下委托的过程，我们看到了另外一种软件工程的可能性。

这就是说，充分发挥基层开发者的能动性和作用，有着本质性的意义。软件开发的组织或许不必狭隘地理解为某种内部控制或者服从，而可以在丰富劳动成果的来源、提炼项目合并的效率、推动不同的开发者都能积极贡献到项目之中，而不是以不同的开发者为工具，更符合科学和实践。

“主动委托，协商合并”和 “主动提交，被动合并”有着不同的适应场景和不同的优势劣势，在这里不做进一步的探究了，有兴趣的同学可以自由探讨。
--
修改:darkk FROM 36.102.208.*
FROM 36.102.208.*