现在保持简单，还是考虑到未来编程？

我目前正在为我的公司编写一个涉及广泛的新应用程序。为了赶上最后期限，该功能已被调低了很多，以便我们可以准备好进行发布。

我的任务是在本月底之前启动并运行版本1。我正处于开发的半途，现在已经结束了。

昨天，我花了一些时间针对其中一项需求提出了一个非常不错的简便解决方案，并且对结果感到非常自豪。今天早上，第2版文档已发出，其中有一项要求将要求删除我昨天编写的代码，或者对其进行严格更改。如果我保持现状，将来将需要大量工作。现在，我可以花额外的时间使我当前的解决方案更强大，以便可以以更少的精力添加v2功能，但这会使我在需要的额外编码上有些落后。

我不知道我是否会做v2。可能是我，也可能是同事，甚至是实习生。

如果您不知所措，您是否会花点时间在将来使它变得更容易，还是在时机成熟时留下解决方案并加以解决？

如果截止日期是“刻在石头上”，只需完成您需要完成的工作即可。确保为新需求增加v2的估算值以适应代码更改。另外，请务必简要记录一下您认为新的v2功能需要更改的内容，以便在您重新分配给其他人员后，同事可以使用它。

如果在截止日期前有足够的灵活性（顺便说一下，为期1天，所以争取延长2.5天），那么可以肯定的继续，为已知的未来编写代码！

避免（早）掉入第二系统效应的猎物。以下是一些适用的好技巧：

1. 绝对不要因为版本2中出现的问题而使版本1脱轨。 提前计划是可以的，但是v2规范的创建者应该对v2而不是v1的失败负责。
2. （如果可能的话）看看您是否可以让创建者重新处理版本2的需求，该需求现在不需要进行较大的更改-然后再计划它们，也许是v3。
3. 请YAGNI一点，但要尽量代码的可扩展性考虑-避免幻数，硬编码值，写出好的单元测试或代码合同等早期应用良好的技术将使得重构和代码更改沿途那么痛苦。

从长远来看，大多数像城市一样增长的软件项目都是成功的。仅在有限的将来进行渐进式规划，您的软件才能按时发布，并具有发布时所需的功能-不再需要其他功能。请参见卡尔·萨根（Carl Sagan）的节选：

如果所有市民系统平行构建并定期更换，[城市]的安排可能会更有效率（这就是为什么灾难性大火（例如伦敦和芝加哥的大火）有时会有助于城市规划）。但是新功能的缓慢积累使这座城市或多或少地持续了几个世纪。

• 卡尔·萨根，宇宙：http://www.eridanus.info/genesis.html

今天不添加代码以符合下个月的要求。今天，您应该写出最干净的代码来满足您的需求。我怀疑现在一天的工作将在几天后节省下来。我已经听到过这样的说法，并且无法回忆起确实如此的一个案例。通过显示一些代码，您也许可以说服我，但是我的经验告诉我，这不太可能。

保持原样。

开发人员实际上会批准一个遗留项目，该遗留项目将执行应做的事情，而不再执行其他任何工作。

今天，对于“分段”代码库以满足“未来”要求似乎是个好主意，很可能会成为将来理解代码的障碍。没有人喜欢处理部分实现的功能以及遗忘的幻象需求的痕迹。我并不是说情况会如此，但是尽管有最好的意图，但事情常常以这种方式出现。

好答案。我只会补充-在这种情况下，我要做的是比较好，这样我就可以捕捉到我所做的事情，并将其松散地放在安全的地方。然后，如果有机会在下一个版本中再次进行操作，这将很容易。

通常，优秀的开发人员会预见未来的需求，但是当最后期限迫在眉睫时，是时候应对您已有的错误，而不是“动摇”了。

这取决于。有一个好的老式规则：像对待自己一样对待其他人。如果这是您自己的项目并且知道所有优先事项，您将怎么办？

如果绝对需要v2，并且最后期限只是一个愿望，而不是刻板的必要，那么不要在天气晴朗的情况下增加技术负担并修补帆。即使其他人愿意做v2，他们也会欣赏他们的远见卓识。

如果对v2的必要性有任何疑问，请坚持使用YAGNI。另外，如果您处于另一端，并且其中有一个客户在他们形成想法之前就不断向您发送垃圾邮件，然后每天只检查您的电子邮件2到3次并且不着急，那么您会感到惊讶在阅读之前，有多少“问题”和请求变得无关紧要。