哪一个更重要:编写正确的代码，还是编写正确的代码？

Question

当我们编写有助于业务的代码时，我们为他们创造了价值，通常是以利润、市场份额等形式。

如果我们写错了代码，我们就不会生成这个值。我们可能会产生一些，但我们将错过这些重大胜利。

A recent survey建议，编写正确的代码-与业务需求对齐-可能不如编写正确的代码有用；给IT上油以产生任何东西，即使它不是很好地对齐，以获得更高的质量。

我经历过一些在技术上令人惊叹但从未投入生产的项目，一些项目在发布时存在缺陷，但帮助企业重新定义了他们的战略，以及所有事情之间的相互影响。你有什么经验，你会推荐什么样的平衡，为什么？

Answer 1

哪个更重要:编写正确的代码，还是编写正确的代码？

乍一看，这可能看起来像是“先有鸡还是先有蛋？”如果我一定要比较这两个，那么我会认为“写正确的代码”更重要。但比这两个更重要的是：“写正确的代码，才能写出正确的代码”

为什么我认为写正确的代码更重要？这是因为“编写正确的代码”的决定必须放在第一位，然后你才能为此“编写正确的代码”。从逻辑上讲，这两者不应该在完全相同的时间发生。真正的例子是:在Sprint Planning中，PO决定“需要做什么”--这是“要编写的正确代码”，在Sprint期间，团队以正确的优先级顺序“编写正确的代码”。

你有什么经验，你会推荐什么样的平衡，为什么？

我也碰巧看到了正确的用户故事正在以一种糟糕的质量方式工作，但幸运的是，它为业务带来了巨大的收益。我也看到了真正高质量的代码产品被报废。这一切可能都是巧合，但有一些特定的概念可能会让这种观察更常见。例如。一种称为“镀金”的概念/实践，其中开发团队花费太多时间来打磨代码，甚至高级开发人员都认为这是不必要的，而团队真正应该做的是，优先移动到下一个用户故事。另一方面，一个花很少时间重构的团队可能很快就会生产出有缺陷的软件，甚至可能给业务带来利润，但“技术债务”最终会杀死他们，如果不是现在，那么几年后，由此造成的损失可能是他们最初可能获得的利润的两倍！

Answer 2

这项调查不是关于软件本身，而是关于IT运营。因此，很难从它得出关于我们开发的软件的结论--它可能在决定何时内部生产软件与购买外部解决方案时更有用。显然，在编写代码时，最好生成正确的代码，对吧。简而言之，这就是敏捷软件运动的全部内容。尽早交付并获得反馈以生成正确的代码；使用单元测试、结对编程、持续集成和持续重构，或各种敏捷实践中的某个子集来生成正确的代码。

Answer 3

如果我需要选择，我会选择Writing the right code (你知道你想要什么，并且你想要正确地构建它--否则你构建的是其他东西)。

但是，我也想说Writing the right code in the right way是一个很好的选择。