Linux 开发过程那么麻烦，是否值得？( 三 )
但是我也希望 Linux 圈外的人能够理解：Linux 所遵循的过程有着切实的优势 。 没有一种工具能完全胜任这项任务 。 以 GitHub 为例 ， 它的工作流程非常好 ， 原则上总是基于现有代码添加新的代码 。 但它可以强行 push 分支 ， 使 commit 上的评论变得毫无意义 ， 使讨论变得毫无意义 。
现代开发工具使许多事情变得更容易：你可以触发动作、集成 CI/CD 流水线、给变更的相关人员发通知等等 。 但在客观上 ， 它们使得我们更难拆分工作了 。 纯文本的电子邮件使许多事情变得更麻烦 ， 但它也并不会妨碍施行能得到理想结果的过程 。
即使可以客观、准确地说出 Linux 放弃这个过程将赢得多少、将失去什么 ， 仅这一点它就是完美的 ， 有理由继续贯彻这个一直运转良好的过程 。
2. 有解决办法吗？我由衷地相信 ， 如果我们有工具可以让一个组织实现 Linux 过程中同样的好处 ， 那将是每个人的巨大胜利 。 面对着这样的工具 ， 甚至 Linux 也可能不再使用纯文本电子邮件了 。
我不知道这样的工具会是什么样的 。 但也许我可以大胆地设想一下：
Git 是一个源代码控制系统 ， 本质上源代码控制系统希望添加历史 ， 而不是重写历史 。 然而 ， GitHub 中的开发过程却把两者混为一谈了 ， 开发和评审以 git 提交为准 ， 而纯文本 Linux 开发人员是在他们自己的本地 git 树中开发的 ， 不断在重写历史 。 也许我们需要将其一分为二 ， 允许在单独的工具中进行开发和评审 ， 这样本质上周期会更短暂 ， 代码更容易得到处理 。 Git 用来存储结果 。 一个很好的类比是 ， CSS 允许 HTML 开发人员将表示层与逻辑层分离 。 还记得 CSS 出现之前的 HTML 吗？不好 ， 我是不是暴露年龄了……
接上述内容继续扩展 ， 可能逐行描述补丁差异会使每件事情都很难开展 。 我们是否可以有一个系统 ， 在这个系统中 ， 我们可以在更高的层次上描述我对代码所做的那些更改 ， 并明确这些变更能够应用到其他什么地方？例如 ， 我可以说“将 create_bar() 函数移到 create_foo() 之前”或者“在 create_bar() 参数列表最后添加一个名为 y 的整型参数” 。 即使后续的变更会在代码环境中添加一些东西 ， 破坏了逐行差异 ， 这样系统仍然能够将变更应用到虽被修改但只是版本稍有不同的代码库上 。 也许我太天真了 ， 这是不可能的 ， 但 GPT-3 取得了一些令人大开眼界的进步 ， 看到这些我觉得可能也并不遥远 。
【Linux 开发过程那么麻烦，是否值得？】或者如果没有那么大的野心 ， 也许有一种中间解决方案 ， 那就是总是对追加的代码进行代码审查 。 如果所有部分都得到了认可 ， 那么此时此刻 ， 也仅在此时此刻 ， 历史才被改写 。 更简单、更易用的工具可以帮助维护者确保与已批准的代码不存在差异 ， 以核实所做的变更都是围绕重组进行的 。
推荐阅读
- 谷歌建立新AI系统 可开发甜品配方
- “全能神”开发谷歌应用APP传播邪教教义
- 联想正开发下一代ThinkReality智能眼镜
- Apple Glass正进入第二开发阶段 目标成品重量轻 续航长
- 运动计数开发项目的对抗赛：飞算全自动软件工程平台碾压传统模式
- 程序员为教师妻子开发应用：将iPhone变成文档摄像头
- 想自学Python来开发爬虫，需要按照哪几个阶段制定学习计划
- 未来想进入AI领域，该学习Python还是Java大数据开发
- 人脸识别设备主板如何选型 软硬整合大幅缩短开发时间
- Linux Kernel 5.10.5发布：禁用FBCON加速滚动特性