您可以左移多远？

当您采用向左移动的方法，并且开发人员开始在编写代码时而不是在完成编写代码时开始讨论代码时，您可以确定可能发生的变化或不太痛苦时的潜在问题或方法。实施左移方法需要什么？

介绍

向左移动的动力一直是尽早发现问题，直到问题变得痛苦和昂贵。

在IBM的Rick Weaver的文章中，“左移原则”和DevOps解释了它应该如何工作，以及左移为何重要的原因：““左移”的前提是我们将通常在较早阶段进行的工作移至其他位置。这是人的天性，但是许多人倾向于推迟特别棘手的问题。[…]最终，当我们最终尝试解决该问题时，这将导致重大问题。下图说明了会发生什么。这也表明需要更敏捷的方法。”

如下图所示，“左移原则”旨在缩短识别问题和解决问题之间的时间。

请注意，该图表未明确引用DevOps，而是引用了Development Progress。那么，为什么在向左移动时DevOps会采取所有行动呢？

残破的开发人员协作流程

典型的开发工作流程始于向开发人员分配票证或任务。开发人员通常会花足够的时间在任何给定的任务上，以构建功能或解决问题，然后通过推送代码并创建拉取请求或合并请求来声明可以对其进行检查。

通常，这是第一次以代码审查的形式提供反馈，这通常不是很长时间，这意味着它发生得太迟了。假设开发人员在执行过程中遇到问题，她通常会要求办公室中的某人进行输入，或者她可以将有问题的代码复制并粘贴到Slack或电子邮件中，然后说明自己要解决的问题。

这些非正式方法不会将流程移至左侧。在询问办公室某人的情况下（很难想象今天发生在COVID-19大流行期间），没有交换记录。在复制并粘贴到松弛的情况下，这个过程是很繁琐（因为你必须要解释你只是从你的IDE移开失去的上下文中），它不经常发生。

如果这样做了，那么交换就会丢失在一个Slack流中，再也不会被看到，它与代码本身完全断开了连接，并且代表了与团队有意义地共享知识的机会。

左移发展

在软件开发中向左移意味着要更早地注意代码的质量。尽管DevOps已成功地向上游发展，并且专门从事CI / CD的公司已成为知名企业，但为尽早提高质量而需要的迭代和关注需要开发团队完全采用不同的方法。

如Devopedia所述：“左移的原理是执行传统上在流程的后期阶段执行的任务，并在较早的阶段执行该任务……左移较少涉及问题检测，而更多地涉及问题预防。

左移并不意味着在流程流中“转移”任务的位置。这也并不意味着在发布之前不会进行任何测试。应该将它及其任务“传播”到流程的所有阶段。这是关于持续的参与和反馈。除了流程的变化外，向左移还与人有关。” 这意味着更好的协作。

左移发展的好处

当您采用向左移动的方法，并且开发人员开始在编写代码时而不是在完成编写代码时开始讨论代码时，您可以确定可能发生的变化或不太痛苦时的潜在问题或方法。

这适用于设计和编码。由于这样做有足够的时间进行深思熟虑，因此代码质量得以提高，测试时间得以减少。结果，总成本降低了。此外，通过向左移动，发布日期变得更加可靠，因为它消除了通常导致延迟的流程结束时的紧缩。

总之，更好的代码，更低的风险，更低的成本和更少的工作量。那么，实现左移方法又需要什么呢？

实施左移发展

除了自动化之外，协作在左移中也起着重要作用。在CodeStream上，我们一直致力于重新设计以代码为中心的协作。它从无需上下文切换就可以交流代码的能力开始。您可以在任意行或任何代码段中评论和讨论，并与整个团队共享讨论，无论是在他们的IDE中，还是在Slack，Microsoft Teams或电子邮件中。

我们最近推出了Shift Left Code Review解决方案，该解决方案使任何开发人员都可以从其IDE中单击两次来请求代码审查。审阅请求可以包括基于其回购状态的任何更改的代码。CodeStream将打包所有更改，并允许开发人员从本地未保存的WIP到已提交和推送的代码，一路选择要包含在审阅中的项目。审阅者通过电子邮件，Slack或MS团队得到通知，然后可以在其IDE中使用完整的源树上下文进行审阅。

与像GitHub或GitLab这样的基于Web的解决方案不同，它们仅向审阅者提供围绕更改的一小段代码，而CodeStream Core Reviews则使您可以以舒适和熟悉的IDE方式访问整个源树，因此没有需要切换窗口或中断流量。

通过在WIP上启用代码审查并对其进行迭代，CodeStream使Shift Left协作成为可能，而无需团队进行重新配置。CodeStream与您最喜欢的所有代码托管平台集成，包括基于云和本地的GitHub，GitLab和Bitbucket。

它还与最流行的任务管理器和问题跟踪器（例如Jira，Trello，Asana，Azure DevOps和GitHub Issues）集成。