前端优先或后端优先。这两个是好的系统设计实践？

我现在有一个客户，要求我开发学校注册系统。现在，这是我第一次遇到这种挑战。我创建的大多数过去的软件都没有那么复杂。

我知道你们大多数人都已经创建了复杂的软件，我只想就此提出建议。我应该先设计前端还是后端？

谢谢！

这是我前一段时间在互联网上找到的一篇文章的结论。只想分享

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

前端与后端开发人员（我的看法）

我个人的看法

同样，这是一个培训问题，一些广泛的笔画概括：

前端开发人员

• 通常没有CS学位，或者没有三级学校的CS学位。
• 使用与基本语言类似的语言（请参阅PHP是基本语言）
• 具有将photoshop文档转换为CSS / HTML / etc的视觉技巧。
• 由于使用无类型语言，因此对迭代编程具有较高的容忍度

后端开发人员

• 有CS学位或丰富经验
• 在他们的问题解决方法上趋向于我
• 不要介意花几天时间寻找一个正在泄漏的物体
• 尝试构建工具来解决问题

如果您从后面开始前进，则可能会误解客户。当您创建他们不容易看到和理解的东西时，他们就不能很轻松地参与验证您是否满足要求。这意味着您可能会浪费很多工作。

如果您从头开始，然后向后走，当您所做的全部事情只是在屏幕上绘制一个简单的表格时，您将冒着客户机将要完成的风险。然后，他们可能会质疑为什么要花这么长时间，因为您几乎在几天之内就完成了。当您意识到自己必须做一些复杂的工作才能使前端与后端结合在一起时，也就冒着将自己粉饰到角落的风险，而更合适的前端可能会更简单。

IMO，您应该首先进行功能开发。针对系统中的每个功能，将前端和后端一起编写。这使客户对进度有了更大的可视性，并使他们有机会说“不，那不是我的意思”，而不会给您带来太多困扰。

就是说，如果这是一个非常大的项目，您需要在其中考虑服务器硬件或所依赖的任何软件的功能（例如，正在使用哪个数据库），那么您可能首先应该对这部分有一个很好的考虑。

软件有很多方面，因此，过于简单的前后对比是一个很糟糕的问题，很难为之提供明智，有用的答案。

一种观点是数据的静态结构。此视图至少包含三个维度：体系结构层（“从前到后”），用例和参与者以及实施的成本或风险。

一种观点是处理的动态结构。此视图也至少具有三个维度。

第三种观点是体系结构组件，它们自然地分为几层，支持用例，并具有成本和风险。

我可以继续，但是重点是这样。

前端与后端开发人员（我的看法）

大约是解决问题的最无用的方法。在这里，实际的开发人员以及您对他们的看法非常重要。重要的是

• 用例和参与者

• 支持这些用例的逻辑数据模型

• 作为用例一部分完成的过程

• 您将用来构建用例的逻辑和处理元素的组件。

这就是为什么大多数人都说您需要根据用户故事或用例来分解系统的原因。

不要对将要发展的人进行广泛的概括。

都不行 您的应用程序需要做什么？确保热阀输送热水，冷阀输送冷水，首先确保水流，您可以在需要的地方延伸管道，然后担心对房屋的所有房间或房屋将要使用的实际水暖系统进行配管看起来真的很像

前端只是一个面罩，上面有一些开关和操纵杆。后端只是接收请求以检索和处理数据的事物。首先，您可以任意组合快速实现这两个目标。

但是无论您做什么，都不要让一个人的设计决定另一个人的设计。那样疯狂。

使用适当的工具，无论您改变主意多少次，开发人员都能为客户构建所需的组件。然后将其构建为规范，然后重新调整它，直到小家伙终于满意为止。

此外，在Web时代很久以前就将2008年的前端开发人员与后端开发人员进行比较。为了好玩，我想对那个旧栗子进行更正/添加一些东西，因为我们已经在问题中将其链接了，但是（希望）在其中嵌入了一些技巧：

前端开发人员

通常没有CS学位，或者没有三级学校的CS学位。

举手。前端有多少人曾获得CS学位的最佳实践培训？或者如何不弄乱JavaScript？或者如何处理来自IE6-IE9的CSS问题？运行于学术界的教科书行业过于懒惰和肿，无法处理不断变化的技术，因此在大学中很少受到“严重”关注。对于像我这样的晚辈来说，这非常好。

使用与基本语言类似的语言（请参阅PHP是基本语言）

因为PHP是客户端技术？还是因为主要受Scheme启发的JavaScript与Basic相比有更多的共同点，而Visual Basic却在前端不再是一个持续关注的问题，而且从不曾如此，但仍可用于后端.NET Web应用程序？我认为，博客现在比较使用公司流行技术的自学型开源Web开发人员和CS研究生Web开发人员。在那场特别比赛的两边，我遇到了无法忍受的能力和平等的能力，但他仍然是场外加油站。

具有将photoshop文档转换为CSS / HTML / etc的视觉技巧。

比“视觉技巧”更注重细节，后者有点宽泛。并非所有人都具有任何美学设计技能。但是，是的，我们大多数人都必须在Jr.级别上学习这些知识，而对于编写在CSS手术刀可以使用时不使用JS锤子的良好UI而言，这实际上非常关键。

由于使用无类型语言，因此对迭代编程具有较高的容忍度

这就是为什么您希望我前面提到的片段优先放置的原因。我们传递按下的按钮，您生产/取货。我们包装并交付它们。这些事情没有任何理由彼此紧密地联系在一起。同样，如果您不喜欢OOP，那么严格的类型应该不会干扰迭代过程，而大多数人喜欢对一门技术上没有类的语言发狂的人，实际上通常会这样做。但是，即使它们确实很臭，前端也只需要一个可预测的访问点，并且只要您不做诸如动态编写不是JSON或将成功的后端行为紧密绑定到“正是如此”的HTML结构。*咳* Java开发者* /咳*

没有一个正确的答案。在某些情况下，这两种方法都可能是好的（也可能是坏的）。

我建议您考虑使用TDD方法，其中一种方法是（验收和单元）测试。

首先将系统的骨架放在一起：基本的基础架构，并具有绝对的最低功能。这只是表明您的概念有效，并且不同的组件也可以协同工作。这还包括一个裸露的UI（如果适用），足以实际执行和/或显示最少的内容。

然后，您逐个特征地充实细节：针对特定特征/场景编写验收测试，使其失败，然后编写满足要求的代码。这使您从外部进行内部工作：系统接收到一些输入消息，因此您需要处理/转换该消息，对其进行处理，然后将结果传播回UI。在此过程中，您将发现领域概念，并用新的类（从UI到领域层再到领域）来表示它们。

对于这种方法，建议阅读的内容是由Tests指导的“增长面向对象的软件”。

API优先

两个团队的工程师应在前端和后端之间的API上共同努力。然后，两个团队都可以根据设计的API开始工作。这具有一个优势，即另一个前端团队也可以开始工作（可能是移动的，在Web客户端之后），而团队可以并行开始工作则具有明显的优势。

结合迭代方法，应如下所示：

1. 设计一个简单的API
2. 两个团队都基于API进行开发和测试
3. 整合测试
4. 向客户展示并接收反馈。
5. 增强API并重复。

从前端开始，但是首先，为什么他们找不到一个已经存在的应用程序？这将对该项目提供更多的见解。他们是否有一些独特的要求，或者他们认为您可以便宜一些？

充分了解他们的安全期望以及法律要求。不知道这是什么类型的学校，但是学生信息通常需要保密。

如果潜在的学生正在网站上输入数据，那么图形设计将是一个更大的问题。

根据他们的要求，绘制前端的模型。如果您认为gui并非直截了当，则可能需要使某些功能起作用，以便他们可以看到它的实际效果。他们可能会将注册视为某种“向导”，它会根据数据输入沿不同方向分支。

然后，您可以开始将信息持久化到数据库中。

是的，我意识到OP问了一会儿。从后端开始，但在前端向上移动，以使用户看到您的构想。前端，尽管值得，还是风声万千。后端是金钱的来源，一旦拥有了笔直的货币，FE就是肉上的肉汁。

扩展我的评论：

首先收集需求，然后将其转变为用例和设计。

首先是详细的数据库定义。我不在乎客户是否没有完全理解它，我强迫他们坐下来看看它，然后在上面签字（可能然后强迫然后意识到，一旦他们的技术娴熟的人应该这样做），然后继续。

如何在没有BE的情况下从FE开始？富裕的原因？？？定义您的数据库！那就是FE所操纵的。

好了，会有问题，稍后再调整，我做的同意，这是很好的得到一个简单，样品，GUI客户端尽快的前面，因为冰山的特定尖是大多数最懂。

但是，我1）强调说，这只是一个粗略的模型（用于讨论海豚），2）故意使它变得丑陋，但功能正常，以便那些不懂的人可以挑剔并告诉我将输入框精确地设为400px宽且背景为浅蓝色。

我认为这里的大多数答案（而且我一直遵循它们）倾向于过多地关注客户，但是，从纯粹的软件/软件角度来看，我主张您必须先设计FE才能操作BE设计BE。