软件设计:快速构建还是构建良好？

Question

在构建一个非平凡的应用程序时，是否最好专注于快速工作，并在代码中使用快捷方式，比如将模型逻辑与视图混合，打破封装典型的代码气味？或者，您最好先花点时间来构建更多的体系结构，并正确地构建它，但是冒着这样的风险:由于您的设计非常流畅，如果反馈导致您走向不同的方向，那么所有这些额外的代码都可能不会被使用。

对于上下文，我正在构建一个桌面应用程序。我是唯一的开发人员，因为我有一天的工作，所以我要做这个兼职。现在，对于工作，我试着做正确的事情，如果时间表允许的话。但是对于这个项目，当我从人们那里得到反馈时，我希望它会改变，我不确定这是正确的方法。这个星期，我花了几个小时，准备了一本教科书“模型视图控制器”()，以便将模型中的更改传递给视图。总的来说，这是很棒的，但我不确定是否需要多个视图来显示数据，而且我知道如果没有附加的体系结构，我本来可以更快地显示事物。也许每周花10-15个小时在这个项目上，我觉得如果我遵循好的软件实践，需要很长时间才能得到一些我可以演示的东西。我知道我的用户不会在意我在内部使用MVC，他们只是想要解决他们问题的东西。但是，我也遇到过这样的情况:你在捷径上欠了太多的技术债，以至于代码很难维护和添加新的特性。我很想听听别人是如何处理这类问题的。

Answer 1

把它建好。

如果你从宏观的角度来看，快速构建它是一个合乎逻辑的谬论。它将阻止您将其构建得很好，最终您将陷入bug和基础架构缺陷的泥潭，这些缺陷会阻止重构，甚至使添加新功能变得几乎不可能。

把它做好实际上正好相反。一开始它可能会慢一些，但最终你会意识到，花时间提前做出正确的选择会提高效率。此外，您将能够更容易地适应未来的需求(如果需要的话重构)，并且您将有一个更好的最终产品，至少，由于较少的bug。

换句话说(除非这是一份一次性合同)，那就是快速构建它=缓慢构建它，构建好它=快速构建它。

另外，要意识到“把它做好”和设计一个体系结构是很重要的。你问..。

...but运行的风险是，所有这些额外的代码可能不会被使用，因为您的设计非常流畅，如果反馈导致您走向不同的方向，您可能不得不扔掉它？

这并不是真正的“花建筑时间”的真正风险。建筑设计应该是有机的。不要花时间设计一个架构的任何部分，直到它是合理的。体系结构应该只从项目中观察到和确认的模式中进化出来。

系统学中的John Gall定律：

一个从零开始设计的复杂系统永远无法工作，也无法修补以使其工作。你必须重新开始，从一个工作简单的系统开始。

Answer 2

快速，然后好

这是我个人的经验，我尝试了很多不同的方法。

仅仅快速工作(和发布)的问题是，通常您会在应用程序中添加一个又一个的特性，而且由于它已经发布，所以很难对程序进行根本的更改。从长远来看，你要付出高昂的代价，因为没有一个健全的底层架构，就像在流沙上建造一个摇摇欲坠的脚镣。

做得好的程序是你会浪费大量的时间和代码。就像建造一座没有蓝图的豪宅。编写应用程序是一个学习过程，几乎(在我的经验中)不可能预先设计。这意味着您将进行大量的重构，如果您一直都写好了所有的东西，那么最终您将丢弃大量的代码。

前面，快，那就好！

当你开始的时候，最主要的事情就是把所有的东西都写进代码中，这样就可以确定所有的特性，看看你需要支持什么样的体系结构。这种方法的另一个好处是，我会让你保持动力，因为你很快就会有一些东西在运行。实现一些“边缘-案例”功能也很重要，因为这将对您的一般体系结构产生影响。在这个阶段，不要费心编写单元测试或处理细节。如果你认为你将来需要支持多语言，一个插件架构的东西，实现它，但快速和肮脏。进行一些重构以保持应用程序的可管理性，但不要过多。

当你觉得自己有了一个工作的“原型”之后，就该开始重构了。基本上，您想重做应用程序，就像从头开始时一样，了解您现在所知道的一切。重要的是要使体系结构正确，而不是重新实现您在第一阶段所做的所有功能，但是您应该有相应的体系结构来支持它。

这样，在我的经验中，您的应用程序将尽可能高效地具有良好的体系结构:)

Answer 3

Build it

如果进入市场的时间比质量更重要，那么如果质量比上市时间更重要的话