敏捷方法论：快速又肮脏还是先计划？

敏捷问题：敏捷是否相信以“快速而肮脏的方式”启动并运行事物？还是敏捷更喜欢从头开始进行牢固构建？还是这不是方法论问题，而是您逐案评估的问题？

从技术上说，我是在“重造”系统的基础之后，我已经构建了很多结构本身……这不是一项艰巨的工作……会敏捷地希望我首先确定整个流程，对其进行分析，进行调整，然后构建？我觉得从某种意义上说这是更好的方法……一旦建立了一个凌乱的系统，我就会更好地了解它是如何完成的……另一方面，它并没有那么有条理……只是好奇什么才是最好的发展实践就是在这方面。

我认为这个问题与敏捷和原型设计有些不同，因为我不是在问原型设计和一次性代码。我对敏捷的生产级代码感兴趣。

敏捷方法是首先计划的。只是没有先计划好一切。实际上，您可以收集需求，设计，代码，测试，部署和演示。您只需花不到两周的时间就可以部署和获取反馈的最微小的功能就完成了所有这些操作。然后，您再次添加所有功能或调整旧功能。

关键是编写接受更改的代码，以便当您最终看到“整个流程应该如何进行”时，可以更改代码来做到这一点。这样，当“流量的流向”（或其他任何方式）再次改变时，就不会造成创伤。

你不能写得又快又脏。快速又肮脏为您提供ridgid代码。努力工作，快一点。通过不传播知识来保持灵活性。理想情况下，任何单个功能更改都应只影响代码中的一个位置。

您也不能花费大量的时间做任何事情，而只能进行计划。您可以计划，但是您需要能够更改计划。您需要快速发现更改计划的原因。当计划进行顺利时，没有什么可学的东西，那就是计划进行了太长时间。规划和编码必须彼此接近。如果您正在学习，则计划越旧，计划就越愚蠢。

从长远来看，您应该计划变得更聪明。编写灵活的代码。然后变得更聪明不会导致后悔。

我不喜欢大多数人的“快速而肮脏的”或“预先的大设计”。他们甚至不考虑还有其他选择。

敏捷就是要建立一个系统，在该系统中，即使是在开发的后期，变更都是微不足道的。这是通过以较小的增量块构建软件，并使用强大的自动化测试锁定这些块的行为来完成的。并在生产中使用频繁的自动化部署来验证这些变更的价值。

通过进行可靠的自动化测试，通过在更长的时间内进行增量重构，甚至更改架构中最难的部分也变得很简单。因此，即使您意识到可以在项目的中途完成更好的体系结构，实际上也可以相对快速地进行更改。

有人说，“预先设计”对敏捷性很好。但是，如果您打算以后迭代该设计，则仍然需要确保您的开发文化产生易于更改的系统。因此，“ SDUF”不会使对健壮的测试，先进的重构和连续部署的需求无效。

通过在系统中构建“易于更改”，您无需费心考虑项目的初始设计，因为以后可以进行更改。大多数人都将“快速而肮脏”的方法称为“尖峰”，仅当您稳定发现有价值的功能时才可用。但是，您不要将被黑客入侵的代码片段留在代码库中的时间过长，因为它们会使更改变慢。

都不行

这是“在前进的过程中从简单开始，不断改进”。

快速而肮脏是脆弱的，但是很快（如果项目足够小且寿命短）。

首先的计划是严格的，但是是稳定的（如果项目在遇到财务或时间限制之前就已完成）。

敏捷是上述2的替代方案。它依靠一种迭代方法，即一次完成一个功能，一个功能一个功能地完成，并且在完成程序的这些功能齐全的部分时获得的知识可用于充实和调整开发计划。为此，需要事先进行一些计划-您至少需要足够的计划才能估计各个功能所需的工作量-但由于敏捷期望发生变化，因此过多的计划会导致浪费。

敏捷的主要特征之一是进行简短的迭代，然后重新评估。您要先探索新领域，从中学习，然后制定计划。这样，您的计划会更好。而且，如果您失败了（发现您的课程构想不起作用），您将“快速失败”，这很好。

因此，您的方法很好。但是危险是然后说：“很好，它可以工作，我已经完成了。下一步是什么？”。您还没有做完，有很多要解决的问题，一旦您确定自己的方法产生了一个可行且可行的系统，就应该花点时间正确地做到这一点。那可能是编写测试，编写文档，StyleCop，优化，教育同事有关您的工作方式和工作方式，进行审查等。

为了增加上述答案，关键原则是YAGNI。如果您的前期设计和规划支持下一步，那就很好。但是，如果它启用了您无法证明的假设性未来步骤，则可以使用YAGNI。

自上而下和自下而上的许多设计都假定将大量重复使用代码。经验表明，尽管代码重用并不常见，因为您很少解决完全相同的问题。如果将来需要解决该问题的变体，请在将来重构设计以添加该变体，但现在不要考虑。

换句话说，为近期任务做好计划，但不要为未来的任何事情做好计划。