Git是您的工作,而不仅仅是您的解决方案

最近,我正在重构一些非常复杂的遗留代码(N路径复杂性得分上的整数溢出)并且没有测试。 这也是产品的重要组成部分,为客户提供了核心价值。 我们希望将大型胖控制器分解为一些较小的逻辑服务,以便我们可以对正在发生的事情进行推理,并迁移一些组件以重用系统的其他部分。 即使这是一件微不足道的工作,也可以轻易将其视为冒险活动,并且需要进行彻底的代码审查。 当我与队友讨论如何进行时,我们实质上是建立了检查清单以及实现结果所应采取的不同步骤。 通过这种排序过程,我开始了自己的任务,但特别注意使用Git历史记录作为我在此过程中所采取步骤的详细日志。 这样,拉取请求的每次提交都很简单(一种更改类型)且具有描述性,例如: 步骤1:将功能主体从控制器复制到服务,无需更改 步骤2:用显式服务注入替换注入整个容器 有些步骤具有上千行的差异,而某些步骤仅改变了几行-但每个差异均由提交消息完全描述。 这看起来似乎很直观,但是很容易退回到将大量的中小型更改集中在一起的趋势,或者仅在更改了特定大小的代码后才提交的趋势。 例如,当您从将要检查您的代码的人员的角度考虑此问题时,很难读取其中可能已移动一些代码并对其进行了一些修改的差异。 另外,它只是彻头彻尾地吸收了数千行代码。 对于请求请求的每次提交,您的提交消息都可以极大地帮助审阅者了解您所做的更改并演示到达此位置所采取的步骤。 当我们压缩并合并拉取请求时,各个提交消息随后将合并在一起成为最终的提交消息主体。 结果,审阅者说这是他们阅读的最简单的PR,我们迅速修复了在审阅中发现的一些问题,发布了没有缺陷的更改并继续进行。

“开发人员至上”的时代已经开始,但缺少某些东西……

开发人员为企业和消费者创造了惊人的东西,使其可以一直使用。 我们一直在不懈地努力,以创造出令人难以置信的良好用户体验,但是当涉及到供开发人员使用的工具和产品时……那么,那些相同的严格标准似乎不再适用……笨拙而复杂的成为新标准。 这是一个奇怪的现象…… 我认为部分原因是我们大多数人没有时间花时间为自己打造美好的事物,部分原因是那一直是过去的样子…… 或至少……以前是这样。 我们目睹了运动的开始。 开发人员要求(和接受)与他们一起使用的更好的工具,他们正在成为各自业务中技术的关键决策者,并且影响力在不断增长。 对于许多人来说,这不是一个新发现,他们看到了这是距离一英里的地方。 像DigitalOcean,Keygen.sh,Stripe,SnipCart,Twilio这样的企业从一开始就都了解这一点,并且专注于为开发人员提供服务。 他们了解,最大化开发人员与其服务集成的生产力是关键。 精明的开发人员正在利用这些新的开发人员至上的工具和服务,并获得生产率的提高。 只要看看流行的开发框架,如Rails和Laravel。 大量粉丝,主要粉丝。 为什么? 因为他们重视开发人员的时间。 聪明的开发人员渴望优先考虑其工作效率的工具,因此他们可以比以往更快地专注于构建令人难以置信的应用程序。 他们知道他们应该得到更好的。 因此,他们正在变得越来越好,变得越来越有生产力。…