全文共3044字，预计学习时长9分钟
来源：Pexels
我最喜爱的主题之一是基于主干的开发。
碰巧的是该主题受到了其他软件开发员的强烈反对。
我喜欢这个主题，因为基于主干的开发直接打击了祸害软件开发员的老套成见。
行业外的人听到“软件开发员”时，会想到软件工程师的神话。几乎像一个神秘人物，戴着耳机，使用着三、四个监视器，黑色屏幕上显示着绿色字符。收到任务的人接着走进他们穴状般的工作环境，直到完成任务为止。
2048游戏的创建者是个很好的例子。传说一位19岁的人在一周内创建了此游戏，在发布后两周半后，游戏玩家就超过了一亿。
这便是完全个性化的守旧软件开发员。尽管有时是挺酷的，但我认为这对团队开发软件有不利影响。
基于主干的开发是一种开发形式，在团队中存在守旧型开发人员时，从字面上讲是无法完成的。
基于主干的开发需要团队合作，同理心和开放的心态。所有这些最好以团队而不是个人的方式实现。
什么是基于主干的开发？
来源：Pexels
基于主干的开发，也称为TBD，是一种软件开发过程， trunkbaseddevelopment.com（所有TBD事物的来源）将其定义为：
“源代码控制分支模型，即开发人员在一个名为'trunk'*的分支中进行代码协作，通过采用有记载的技术，可以抵抗创建其他长期存在的开发分支的任何压力。因此，他们避免合并，不破坏构建，并从此过上幸福的生活。”
其概念不是创建一个开发人员开发代码的特性分支，再整合为主分支，而是以小版块的形式开发该功能，完成后将每个功能块直接推送到主分支上。
换而言之，团队开发不需要使用任何分支。
现在……我知道，从事该行业已有一段时间的大多数开发人员在看到“推送到master上”后会立即打消使用TBD的想法……但是请听我说，我将在本文尽力解决我听到的问题。
它为何如此重要？
我再次回到《加速》中定义的四个关键指标及其重要性。这本书的直接引文：
“我们的研究强调了成功进行技术改造必不可少的经验。其中包括使用版本控制，部署自动化，持续集成，基于主干的开发以及松散耦合的体系结构。”
这些实践行为不仅重要，而且是基本的。意味着这是绝对必要的。
基于主干开发格式中的少量代码更改造成合并冲突（意味着更快乐的开发员），除了这一事实外，基于主干的开发可以帮助团队在许多方面进行改进：
部署频率和恢复的平均时间
与CI / CD管道配对使用的TBD会导致每个“绿色”提交（即已通过测试并经过检查的完整代码功能）被部署到生产中。将所有更改推送到主分支意味着大量集成和潜在的部署。我曾在团队中工作，一天之内就将其部署了30–40次。提高部署频率是四个关键指标中的第二个。
我记得，在同一支团队，我们曾在前端应用程序中部署了一些东西，就是“显示具有各自属性的项目列表”，而我们忘记了检查空值或未定义的值。这导致前端出现错误。
当然，无论团队使用什么流程，这都是可能发生的事情……但是令人惊讶的是，我们立即注意到了这一点，并且能够在五分钟内针对已提交并部署到生产环境中的问题进行测试和修复。平均恢复时间短是四个关键指标中的第三个。
发现问题时，通过基于主干的开发和CI / CD快速部署更改的能力也使团队进行“前转”，而不是“后转”。
代码质量和知识共享
团队在考虑TBD时通常最担心的是，在进行基于主干的开发时，代码库中的代码质量会受到影响，并且出错的可能性会上升。但是，我有完全相反的意见，并且相信TBD会产生更具弹性和更高质量的代码。
大多数使用特性分支的团队都使用合并请求方法，团队中的其他开发人员将查看和评论开发人员花费X倍的时间处理过的代码。
使用TBD，由于没有特性分支，也就意味着没有合并请求。在此处插入忧心忡忡的高级开发人员。这不一定是问题。大多数团队只想要一个“四眼原则”，该原则表明至少有2个开发人员应该查看并批准所有合并到主分支中的代码。
我的团队也执行“四眼原理”，但我们通过结对编程（即将推出）进行操作。由于TBD中没有合并请求，因此结对编程变得非常必要。
通常，相比开发人员独自解决同一个问题，两个开发人员共同解决会更好。所有开发人员对团队开发的技术堆栈和/或系统都有不同程度的经验和熟悉程度。彼此配对提供了快速向队友学习的机会。
想象一下，与团队中的高级工程师配对时，初级工程师或新员工的提升速度有多快。团队编码准则可以立即学习并得到满足，在工作完成之前就可以做出设计决策，而不是在合并请求中作为反馈，并且代码是一起编写，从而使两个开发人员都知道其工作原理（更少的知识库）。
团队合作
来源：Pexels
显然，结对编程也是团队合作的一种形式，但是TBD要求所有成员具有同理心的方式，因此改善了团队中的合作精神。
一名在系统上工作了多年的资深开发员，在看不到代码库的情况下，要与专注于代码库的新手或经验不足的团队成员共事，这可能是具有挑战性的。但是具有同理心的人能够做到，这是作为队员非常优良的品质。相信自己的队友能够胜任工作，而不必成为主分支的负责人，这对建立团队内的信心和信任非常重要。
.高级工程师很聪明，并且大多经验丰富，但是他们团队中的人也很聪明。如果高级工程师想看到初级工程师编写的代码，他们可以结对，并且远比他们知道的早，初级者将编写出高级人员会为之骄傲的代码。
潜在挑战：
未完成的功能
没有人愿意将尚未完成的功能（例如没有功能的按钮）推向生产中的客户。为了解决这个问题，团队可以在隐藏未完成功能的背后实现功能切换。如果未完成某项功能，功能切换会关闭，而当完成最后一部分并准备发布该功能时，可以打开（或完全删除）功能标志。使用功能切换，团队甚至可以进行A / B测试或Canary Release。
测试与监控
基于主干的开发要求团队具有强大的测试套件和良好的监控，以便尽快发现错误。反馈回路越快越好。中断的管道成为断开管道的团队成员的头等大事，以防止其他任何人提取中断的代码。
可以通过实施微小的更改，拥有与测试和生产环境尽可能相似的开发环境，并且在推送之前在本地运行管道任务（例如使用git hooks），轻松防止这种情况。
我知道许多团队已经按照本文中的描述实现了基于主干的开发，但是他们都没有切换回更常见的合并请求模型。
一些团队甚至出于其他原因而切换到基于主干的开发，例如，他们想进行更多的结对编程，从而切换到TBD，以使结对编程具有更高的要求。
我认为要记住的是，如软件中以及生活中的所有事物一般，同样的东西并不适用于每个人。重要的是，团队要研究最适合自己的方法。例如，我认识一个团队，他们的开发人员数量是奇数，这意味着他们没有能力完成所有任务的结对，有时会因频繁的结对而精疲力尽。在这种情况下，他们具有在同一天创建和合并的特性分支，将其视为TBD，真让人惊讶。
来源：Pexels
下一步：尝试基于主干的开发，使其适应团队的需求和利润。
留言 点赞 关注
我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”
（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）
