12!配对_配对编程进行救援！

12!配对

那些已经阅读过我的文章的人可能已经注意到，我是一个非常热衷于干净代码的开发人员。 造成这种狂热的原因并不是我对纯净的美丽着迷，因为我从未将代码视为艺术。 我非常专注于编写干净的代码并保持代码的可读性，因为…我是一个非常懒惰的人。

我只是认为易于理解的代码使我（而且不仅是我）的工作更加轻松。 我不必花费大量时间浏览代码并寻找问题的答案。

我知道在代码库中引入一些新的东西时会花费很少的精力，将来会节省很多时间。 但是，如果我是项目中唯一对编写自我描述性代码充满热情的人，这将是不可能的。 必须是团队合作。

这么多知道如何做好的人

我认识的大多数开发人员都同意在软件开发方面有哪些好的做法。 持续重构 ， 编写良好的测试 ， TDD ， 代码审查等等。

在喝咖啡的讨论中，他们谈到了遵循这些做法所带来的好处。

然后他们回到办公桌前，……不知何故他们没有重构代码。 为什么？ 因为“我在区域内，伙计” 。 他们没有写测试，因为“截止日期太紧，我很着急” 。

也许您也经历过。 也许你现在摇头。 然而，它发生了。 我看了太多遍了。 那些正在向其他人传福音的优秀开发人员，他们……嗯……忘记了编写代码时他们在说什么？ 也许它们是如此的好，这些做法不再适用于他们？

不做吗

也许就像停止重复一样简单，那么TDD（以及重构，代码审查和其他实践）是如此之大，因为以这种方式编写代码有助于我们提高代码的质量和可读性吗？ 好吧，我提出了几次，但我总是遇到反对的声音。

好吧，当您不做某事时，就不要说服他人去做。 听起来合理，不是吗？

但是，没有人对此达成共识，这当然是件好事，因为在我分享自己的主张时，我的意图是唤醒周围的开发人员，而不是停止遵循这些做法。

很好，但是没有解决问题。 那么有什么可以帮助的呢？

配对编程进行救援！

我能理解那些喜欢以更轻松，更熟悉的方式做事的人。 以他们有一定经验的方式。已知总是比未知更好。 已知比未知更容易。 如果人们没有在TDD方面的经验，他们会喜欢以其他方式编写代码。

但是，他们不是颂扬TDD的人吗？

答案是肯定的，这可以成为优势。

配对是可以帮助开发人员获得一些经验的做法。 为什么可以运作？

在没人看的地方，找借口比较容易。 说服自己，以更好的方式（更快，更轻松）以传统方式制作，而不用为此花哨的TDD苦苦挣扎。

我认为我们大多数人会尽可能选择较少的努力。 正如我已经写过的那样-知道更容易。 但是更好吗？

当我们独自一人时，就会发生这种情况。 当我们不必向任何人解释为什么我们不遵循我们强烈建议的做法时，以这种方式编写代码非常容易。

当我们与另一位开发人员坐在一起时，情况会发生变化。 我们不再愿意不遵循建议的做法。 为什么？ 因为我们将不得不自我解释。 我们必须找个借口。 不是一个微不足道的借口，而是一个扎实的借口。 而且很难以此为借口。 因此，我们正在选择更简单的方法–我们正在遵循这些做法。

我们正在改进代码，正在从头开始以良好的方式编写代码，正在编写描述性测试等等。

太好了，我们不断尝试最小化完成某件事所需的精力。

让我们将其用作优势！

翻译自: https://www.javacodegeeks.com/2016/10/pair-programming-rescue.html

12!配对