我们是否应该创建底层架构来增加灵活性--提前还是在需要的时候？

Question

在这个问题上我问:设计更多抽象级别以允许松散耦合的成本是否值得获得好处？

人们说，这通常是值得的，但人们应该意识到，他/她的应用程序以后是否真的会使用这个底层的设计，或者它是否会浪费时间。

我的新问题是：

我们是否应该预先创建基础设施以允许灵活性和可维护性--从而使开发变得“更干净”和更“有组织”，因为开发是在现有的基础结构和抽象级别上开发的？

使用这种方法，您可以设计底层的基础结构，而不太了解以后将如何实际实现。因此，您可能正在编写以后可能不会使用的代码，并且浪费您的时间。但是，发展将更加清洁和有组织。

还是应该创建基础设施，以增加灵活性，并使事物在实现过程中更加松散耦合--从而在以后可能不会实际使用的事情上浪费更少的时间？

这种方法阻止您编写不被使用的代码，但强制您设计基础抽象级别和现有代码的设计，从而修改现有代码，而不是在编写使用这些设计的代码之前对底层设计进行编码。

方法1的示例：“好的，现在我们开始将应用程序的这一相对大的部分进行处理。这部分通常与对几个GUI的响应有关。让我们为程序的这一部分建立一个底层的抽象级别，以便稍后在我们实现它时使用。”

方法2的例子：“好的，我正在设计程序的这一部分。在做这个部分的时候，我看到这个部分最好是松散耦合的。让我们再做一个抽象级别来允许它，并修改这段代码来使用这个抽象级别”。

哪种方法更有意义，还是更普遍？

Answer 1

坦白说，两者都是。

在几十个地方编写和绑定所有代码之后，就不可能添加抽象层了。可悲的是，如果没有实际操作并看到事情的发展方向，就不可能完全正确地获得所有抽象层。

所以在实践中，你最终会兼而有之。您在开始时添加了一些抽象，试图在灵活性和过度工程之间建立联系。在非常有可能是必要的地方，或者如果你猜错了，它将是灾难性的，你就会创造出灵活性。长话短说，你可以减轻风险。

然后，随着时间的推移，添加或删除抽象。重构是使代码“适合”的关键。有时候你会发现事情太复杂了。有时候你会发现事情太耦合了。随着时间的推移把它清理干净。

这种感觉是“足够了”，而抽象在哪里是随着时间的推移而发展起来的关键技能，因为你做了设计，看看它们是如何成功的(或者更多的时候，失败)。

Answer 2

我建议不要使用第一种方法。编写代码是一个发现过程--就像没有任何计划能与敌人接触一样，每个设计都会有缺陷，只有当你开始实现它时，才会发现这些缺陷。此外，你可以抽象任意数量的方向和水平的任何东西。如果您为太多的" what -ifs“进行设计，那么您的体系结构将无法与您的需求保持一致；如果走得足够远，您最终会得到一些可笑的东西，比如格林斯夫第十定律或内平台效应 (想想看--如果所有东西都是可定制的，那么剩下的就是一种编程语言)。

最重要的是，您正在追逐一个移动目标(更改需求)。即使你现在奇迹般地得到了正确的设计，也不能保证以后它仍然是相关的，就像你说的。

总之，这是个滑坡路。它不能提供即时的价值，而且很有可能它会引导你走向错误的方向。

Answer 3

Python社区有一个很棒的工件：“Guido‘”。也就是说，许多人对Guido在Python中设置语法和机制的远见感到惊讶，这证明了随着时间的推移，语法和机制的工作非常清晰和直观。

然而，并不是每个人都有时间机器，预测需求可能是很棘手的。

在敏捷中，规则是“接近需求的程序”。在TDD中，它是“最简单的解决方案”。

然而，在蛮力实现和抽象以预测未来的需求之间有一种平衡。

IMHO很重要的一点是：( a)留意好的抽象，以提供干净、灵活、可扩展的代码；( b)提防将项目变成一个过度通用的基础设施，实际上什么也不做。

很多时候，我会在业余时间在我的副业项目中做一些宽宏大量的事情。但我仍然在会议上畏缩，当一个工程师，在任何水平的经验，对某种机制将解决世界的问题感到兴奋。

在一天结束的时候，确保你把功能放在客户面前。但是，在有针对性的应用程序中，要保持抽象的能力。