对于大多数网络开发大师来说，我的问题听起来很愚蠢，但作为新手，我想问一下我是否可以只在后端之后开发前端？
另外，如果我需要数据库，我应该先设计它吗？
我也想了解项目的分析部分。一位朋友简短地告诉我，开始项目需求分析（内部、技术和设计）是必须的。假设我想建立一个能够让用户注册的社交电子商务网站。您能否确定一个编号列表，您将如何为此类项目准备分析（等 1. 数据库设计 a）准备数据模型...）
如果有人能提供详尽的答案，我将非常高兴。
谢谢。
问候， 唐尼
【问题讨论】：
我通常在前端 1st 中决定我需要哪些字段。
然后开始处理数据库后端..然后是带有单元测试的中间层..最后是前端。
当然，一旦我开始做前端工作，我会想到更多的领域或数据库的变化......这就是开发的本质。
【讨论】：
我认为这个问题实际上是自下而上或自上而下设计更好的问题的变体。 我发现它有助于做前端的草稿来模拟网站的典型使用。这有助于人们看到需要的后端选项，否则会错过（考虑需要的数据）。
【讨论】：
特别是当新人参与项目时，我建议采用渐进式方法。
选择一些你知道你会需要的功能。从数据库（SQL）开始，然后是后端代码（也许是 PHP），然后是 Web 前端（HTML）。使完成这一功能块的过程尽可能简单。事情的顺序并不像一次只处理一小部分那么重要。
一旦该小部分起作用，请保存一份副本。版本控制，甚至。这样一来，如果你明天搞砸了，你总能回到原来的工作上。
然后选择下一个小功能并添加它。我总是觉得这很激励；你会看到持续的改进。
我可能会在数据库级别提前计划，因为虽然对 HTML 的任何更改只会真正影响 HTML...数据库更改通常需要后端代码更改，而后端代码更改通常需要更改 HTML，并且必须重做所有事情是痛苦的。
【讨论】：
您应该构建您期望存在于整个系统中的层。每一层都可以由不同的人并行架构/实现，但是集成点需要协作来决定合同。
有两种通用的接口/合约模式：
1) 消费者/应用程序需求 -> 接口/合同由应用程序决定，并且编写下一层以符合/适应这些需求。现在，所有层级基本上都由其下游消费者驱动。优点是您可能需要最有效和有限的一组方法，缺点是需要做更多工作才能使系统适应其他消费者。
或
2) 服务提供者 -> 接口/合同由服务决定，该服务旨在支持一组核心通用功能，这些功能可以服务于许多应用程序，甚至一些应用程序尚不为人所知。然后，使用提供者的应用程序必须根据其内部需求调整合同的功能。优点是该服务无需修改即可更方便地重用，但这些通用方法可能不太适合任何特定应用程序的需求。
这些都不是完美的答案，这取决于具体情况。上述 1 或 2 的决定也可能会有所不同，具体取决于您正在处理的层连接。你可以有一个服务合同 #2 的服务，一个应用程序有自己的需求合同 #1，然后是一个适配器层，将应用程序需求映射到服务的功能。
无论您使用哪种模式，层的架构、它们的合约以及它们之间的交互方式都比您开始在任何特定层上工作时更重要。
一般来说，一旦层级设计到位，您就可以在定义合同的层级上工作，并跟进使用合同的层级。
【讨论】：