需求得到修复以及您编写的代码不必更改的想法非常棘手。实际上，要求永远不会得到解决。无论您是否需要在初始发布之前更改它，在将来的某个时刻，您的代码很可能需要更改。当这种情况不再成立时，这是因为代码库被放弃了。
在您的情况下，您已经确定1.您的初始要求不是您最终提供的要求2.您不能影响对该现实的任何改变。
所有这一切都指向一件事：您需要围绕变革能力优化您的发展战略。您将在此处阅读的许多软件实践是关于以后理解代码的能力，修改的容易程度，或两者兼而有之。
我建议的第一件事是，在向产品所有者展示之前，您不再尝试构建完全完整的抛光系统。而是建立功能原型并尽早将它们提交给决策者。收集他们的反馈，实施它们并使事情更加完善。再次向他们展示。冲洗并重复。最终，除了细节之外，你应该开始说一切都好。那是你开始完成任务的时候。
另一件突出的事情是，当你进行这些更改时，你正在攻击它们。你应该遵循相同的代码标准，无论是最后一刻的更改，还是你的代码在6周内没有到期。是的，你可能需要在最后一分钟调整一些东西，然后每隔一段时间清理一次，但是在常规版本中执行此操作会对代码库造成极大的破坏。编写的代码编写得越差，就越难以适应变化流。尽早将它放在人们面前将有助于此，因为您将有更多时间适当地进行更改。
我要推荐的最后一件事是一些特定的开发实践，在这种情况下可以提供很多帮助：
模块化代码：如果不出意外，请确保将代码分解为具有单一责任和有意义名称的简短可读方法。
单元测试：对单元测试经常产生误解的是，它们在确定代码是否符合要求方面的价值相对较小。它们闪耀的地方就是你修改代码的时候。当你破坏了东西时，他们会给出即时反馈。在实施更改之前，请使它们保持最新并修改您需要先更改的测试。
