当我们编写有助于业务的代码时，我们通常以利润，市场份额等形式为他们创造价值。哪一个更重要：写正确的代码还是写正确的代码？
如果我们写错了代码，我们不会生成这个值。我们可能会产生一些，但我们会错过那些大胜。
A recent survey建议，编写正确的代码 - 适应业务想要的东西 - 可能比写代码的权利用处不大;使IT产生任何东西，即使它没有很好地协调一致，也会产生更高的质量。
我已经经历了它在技术上惊人的，从来就没有生产项目，这是越野车的释放，但帮助企业重新定义自己的策略，和一切之间，反之亦然项目。你有什么经验，你会推荐什么平衡，为什么？
哪一个更重要：写代码的权利，或写正确的代码？
乍一看，这可能看起来像“先来了，鸡还是鸡蛋？”问题，但事实并非如此。如果我绝对必须比较这两个，那么我认为“编写正确的代码”更重要。但是比这两个更重要的是这样的： “编写正确的代码，为正确的代码写入”
为什么我认为编写正确的代码更重要？这是因为“编写正确的代码”决定必须先放在第一位，那么您可以“为此编写正确的代码”。这两个逻辑上不应该在同一时间有意识地发生。真正的例子是：在Sprint中规划PO决定“需要做什么” - 哪个是“要编写的正确的代码”，并且在Sprint期间，团队“为代码编写正确的代码”来编写正确的代码“，按正确的顺序排列。
什么是你的经验，你会推荐，为什么什么平衡？
我也偶然看到正在以不良品质方式工作的正确用户故事，但它幸运地为业务带来了巨大收益。而且我也看到了真正高质量的代码产品被废弃。这一切都可能是巧合，但是有一些概念可能会使这种观察被更频繁地看到。例如。一个被称为“镀金”的概念/实践，开发团队花费了太多的时间来完善代码，甚至高级开发人员认为这是不必要的，当团队真正应该做的是，接下来转到用户故事优先。另一方面，重构时间很短的团队可能会迅速生成有问题的软件，甚至可能为业务带来利润，但“技术债务”最终会杀死他们，如果不是现在几年之后，那么损失由于这可能是他们最初可能获得的利润的两倍！
如果我必须选择，我会去Writing the right code（你知道你想要什么，你要正确地构建它 - 否则你是别的东西建设）。
但是，我也想说Writing the right code in the right way是要走的路。
很显然，没有一个正确的答案 - 但我的首选作为工程师的目的是尝试生成内部“正确”的系统，它表现出良好的软件特性（功能强大，解耦，连贯等）。如果我没有做他们需要的事情，商务人士会纠正我，并通过发送备忘录和Jira条目来纠正我;质量差，以更微妙的方式出现。
该调查不是关于软件本身，而是关于IT运营。因此，很难从它得出有关我们开发的软件的结论 - 在确定何时生产软件与购买外部解决方案时，它可能更有用。很明显，在编写代码时，最好编写正确的代码。简而言之，这就是敏捷软件运动的全部内容。及早提供并获得反馈以生成正确的代码;使用单元测试，结对编程，持续集成和持续重构，或者使用各种敏捷实践中的某些子集来产生代码。
如果您问的是您提出的问题，则在此过程中出现故障。如果您的需求工程工作正确并且能够正确访问正确的客户和利益相关方，那么您不必担心（尽可能多）您是否正在编写正确的代码。
每一位医生最终都会将一种症状误诊为实际问题，而不是将其作为一种潜在问题的症状的适当位置。这不应该是常态。
但是，如果您的企业客户不让您接触客户或以其他方式妨碍需求工程流程，那么您编写代码的权利将清楚地表明，开发流程的问题不是“在你的最后。另外，如果您要编写正确的代码，并为已经指定的需求编写正确的代码，那么迭代开发方法应该在流程的早期指出其他方法是不正确的。
我不认为这就是回答问题，是吗？编写代码是程序员工作中最小的部分，所以如果我们将其他60-80％的工作做好，那么我们应该始终写出正确的代码，这使我们有更多时间来编写代码。
也许在程序员。 – dmckee 2010-12-10 02:47:05