重构是一个让许多人感到恐惧的词，从开发者到产品负责人，以及介于两者之间的一切角色。在很多方面，它可能和脏话一样。我们也经常在这里谈论它，因为，就像 关于该主题的书籍、从哪里开始，以及 技术债务累积的影响。
Ben Rady 也对重构有自己的想法，但在结对编程的背景下。
我们每天结对大约 6 个小时。关键路径上的所有内容都由两人合作完成。一直如此。我们的目标始终是尽快负责任地将我们正在处理的内容推送到生产环境，而我发现最好的方法是结对。
然后，Ben 深入探讨了与他人一起工作以及如何使用这种方法发布软件的过程，我认为其中很多都与前端开发最佳实践相关。但我也很喜欢这个团队的朋克摇滚精神，因为他们似乎没有使用积压工作或大量会议来管理他们的项目进行软件开发。
没有正式的积压工作。我们为新功能设置了三种状态：现在、接下来和可能永远不会。我们现在正在处理的内容是我们能想到的最有价值的东西。接下来的是第二有价值的东西。当我们提取新的工作时，我们会问“接下来是什么？”并进行讨论。如果有人向我们提出一个想法，我们会问“这比我们计划接下来做的事情更有价值吗？”如果不是，通常会被遗忘，因为在我们完成它之前，会有其他更新更好的事情出现。但如果它再次出现，也许它会入选。
我想知道他们每年节省了多少时间，而不用争论故事、分数以及这个微不足道的功能是否比另一个更重要。总之，我发现所有这些东西都非常鼓舞人心。
这非常有用。还有来自 scrum 的 MoSCoW 方法——必须有（项目成功取决于它）、应该有（将非常有用，但成功不取决于它）、可以有（不错，但不是必需的）。“W”代表想要有，但我倾向于将其与可以有归为一类，因为我发现三个层次的需求就足够了。