如何在设计和(实际上)实现应用程序之间取得平衡？

Question

我的问题不是编程语言的具体问题，而是它更一般的问题来看人们的思维方式。

通常在大型开发公司中，每个工作都有特定的角色，例如程序员和架构师。因此，架构师的观点是拥有一个完美的架构师和解决方案设计，而另一方面，程序员正在处理的是实际实现应用程序特性和UI之类的事情。因此，如果让架构师(例如，在没有out程序员的情况下处理应用程序)，您就可以从外部获得一个完美的应用程序(设计模式、类、DB表)，但是没有外部的应用程序，反之亦然。程序员总是专注于输出，而不太关心设计原则(例如，实心原则)。

现在我在一家小公司工作，团队成员最多为8-10人，所以您需要处理您的应用程序设计以及实现这些特性。所以我的问题很简单

• 什么时候需要停止设计和实现您的解决方案？
• 还是应该是增量式的工作？
• 如果你一开始就因为设计不好而搞砸了怎么办？

我希望我们能有一种不同的思维方式，这样我们就能想出多个可以接受的解决方案。

Answer 1

彻底考虑一个问题/设计将改进最终代码。但是，除非您在编写代码时花费数月时间在设计上，否则您将发现设计中的缺陷、您没有想到的新特性，或者您没有预料到的交互。在大多数软件项目中，目标-帖子会移动(客户会想要一些稍微不同的东西，或者你会有一个很好的想法，部分通过，等等)。

瀑布学徒倾向于先完成整个设计，然后才知道代码将如何完成--这是不灵活的，导致设计缺陷被发现太晚，无法做太多的事情。通常，甚至在瀑布方法中，我建议原型化，在设计阶段实际实现高风险编码任务的程度足够大，以确认它们可以完成，并按需要工作。

敏捷方法建议您只需要开始设计，然后在发现需要时再进行更多的设计。这将编码与设计混为一谈，并提供了一种更加灵活的方法。然而，这常常被误解为“没有设计”，或者设计的大部分直到太晚才被考虑--这不应该是这样的。您应该设计足够的总体结构，以使您了解如何继续进行设计，并且您尚未精确指定的设计的小部分非常简单，您知道您可以在不影响最终产品的情况下设计它们。

因此，无论你走哪一条路，你都需要有足够的计划，让你知道你要去哪里，在需要的时候灵活地改变方向，但是在过程中写一些代码(原型或最终代码)来帮助指导你的设计。如果部分程序被证明是不够的，那么就准备重写它们。

Answer 2

任何类型的编程项目从根本上说都是一个迭代过程。无论是让一个程序员来做所有的事情，还是让一个庞大的团队分成几个小组来处理整个系统的零碎部分。

这就像一句古老的军事格言：No battle plan survives contact with the enemy。即使是最详细、最具体的发展计划也会遇到道路上的一些颠簸，需要对项目的某些部分进行修改。而且，如果客户端在项目达到各种里程碑时输入了内容，那么他们总是想要更改，或者想要放弃一些东西，从头开始。

甚至团队成员之间的反馈也会导致变化。数据库模式架构师可能已经提出了一个出色的模式，它在纸面上看起来绝对完美，但在实际实现时却表现得像块砖块。编码器本可以为程序的某些方面实现一个绝对华丽的算法，但是它最终会吸掉太多的RAM，最后你会回到一个更丑陋但更有效的方法。

不管你最终使用的是什么开发方法，事情都会改变，你只需要适应。找一些对你和你的团队有用的东西，然后跟它一起去。