自己做项目，一般是先写前端还是后端？

你是不是有活，可以外包出来，锻炼下自己项目管理 [手动狗头]

我一般先写前端

我一般都是 先根据原型整理一下功能，后端先行，然后前端展示数据...

先前端，毕竟看得到

肯定先前端，因为这个立刻能看见。

我不是写前后端的，主要写 C/C++驱动那块的东西。不过最近公司需要写个网页能用的管理平台，公司只有我业余时间写过（我也是个前后端的半吊子）。
我是先写的前端，然后可以根据前端的设计来制定接口，免得写了后端之后，接口设计不合理导致需要重新设计接口和数据库的尴尬。

先前端吧，客户问进度的时候可以给他看

先设计数据库

数据库->后端->前端->后端->前端->后端->前端->后端->前端->后端->前端…………

真的写代码的时候，最好是先写数据库 schema （或 model ），这个才是整个项目的核心，同时也是后续修改起来比较麻烦的地方，会想尽量减少修改次数。

把数据库 schema （或 model ）思考得非常清楚的时候，在脑子里就有整个项目非常清晰的骨骼，剩下就是后端围绕数据库做增删改查和前端美化。

不喜欢写界面，所有先写前端，前端写完能长舒一口气

作为后端程序员，习惯先后端搭个架子，这样才会感觉思路有个主线。然后围绕需求，先前端再后端。
前端方便展示进度也是一个很重要的因素。
go 比 js 开发效率高也是。

一人独揽的话，先前端，能更高效的确定所需要的数据，然后才是完成数据库表设计，最后是业务逻辑，接口的输入输出是什么。

通俗的说，确定数据流的终点在哪，起点在哪，最后设计具体路线。

一起不香吗?

公司项目，先画原型 UI，然后设计数据库，然后写后端，然后写前端。

先出需求分析和原型啊

数据库设计 -> 接口定义 -> 前端 -> 后端

工具类的先写前端问题不大，需要保存大量用户数据的，做之前反复推敲数据表设计，这是基石。后期迭代过程中，最危险的就是增删用户表、迁移用户数据。生产机上的数据变迁那是边开飞机边维修的活，前期设计不合理，容易机毁人亡。前端的内容，随便怎么迭代，影响限于颜值范围，不破坏数据的回滚也容易。

一个一个功能写

先搞清楚需求,把数据库和原型搞出来 然后照着来就行了

必须先做前端

理由：个人开发不会去做需求分析，画原型图什么的，思考不一定很全面。先做前端的好处是相当于系统性思考了，不要后端也能出个 demo 先把玩一下，感觉不好地方及时修改，才知道需要后端那些接口

用什么平台也很关键。

用 PHP+MySql 时，我习惯先设计数据库，然后后端伪代码->无样式前端->后端具体代码->美化前端

现在以 AWS Serverless 为主，顺序就成了先做前端大致框架，然后后端伪 API->设计数据库->后端具体代码->美化前端

其中最主要的变化有两点：一是数据库设计后移，这是 DynamoDB 的特点决定的；二是前端开发提前了，因为 React 开发会用到大量的开源组件，这些组件对数据源格式的要求不尽相同，先做这些可以更好的设计 API，减少对数据的二次加工。

数据库设计，api，前端

@lihongming 一直是传统开发，我是不是要看看学学 serverless 了，区别很大？

先写后端完全摸瞎，以前是看心情写，后来是先写前端了。

很明显要先写后端，至少写到能输出前端需要的基本数据，然后前后端一起进化。先写前端数据哪里来的？

自己一个人一把梭，还分什么先后，当然是一边写前端，一边写后端啊。

一个人的话，分啥前后端啊，一锅端了

@jakezh 真实

@love 当然是用假数据了。简单的用*.json 和*.xml ，高级点的用 mock.js 。

9 楼正解

我一般是先想好要实现的功能，然后定好大致的数据结构
先写后端传输假数据，再开始搞前端，配合着改后端。。

因为这个过程中，你会慢慢发现很多功能实现不了，然后慢慢的阉割.....

1 、设计功能
2 、设计数据库
3 、定义接口
4 、写后端然后前端

做项目都是按功能需求来得啊，哪有想到哪做哪得。功能模块-> 前端布局(模拟数据) -> 后端接口。这样应该是比较舒服的把

设计表->功能 A->前(mock)->后->功能 B->前->后。。。
对于每个相对独立的功能 /模块的开发周期内 是同时包含了前和后的

@love mock 一下就行了呗

先前端，前端下来不用整理一眼就能看清结构

画原型 --> 创建 json 的 mock 数据 --> 前端 --> 根据 json 文件生成建表 sql --> 后端 --> 调试

先前端，因为前端就是测试(狗头)，这样就有测试驱动的模样了(再次狗头)

个人感觉是前端先行吧，说白了后端的接口就是为了前端信息展示提供服务的。在你先写前端时，能够比较容易的加深你对产品和需求的理解，知道你需要个什么样的接口，这样在你后前编写起来前端时就能得心应手的。

我后端，表示先写后端。因为先写前端的话要 mock 数据。先写后端的话不用 mock 。

先写 api

先数据表
再接口
然后随意,一般前端开始吧,毕竟调接口文档比调接口简单.

怎么可能是先前端？肯定是数据表规划好，数据结构不清楚，怎么写前端？

先摸清需求，然后出原型，设计数据库，后端，再前端，代码不用着急写的

菜鸡的我先后端，然后在前端，不然数据交互有点懵

主要看思维模式，如果想的通透，哪里开始都一样

先画图，架构图，流程图，ER 图，再写后端，单测，再前端。

自己的项目，即便再省，ER 图，单测最好别省。

先写后端，先写前端最后可能会发现项目一多半的时间都在折腾前端，包括但不限于 CSS 、组件选择、等打包。。

后端未动，前端先行。写死链接，能用就灵。

先画页面，再设计数据格式，再写前端。

原型和业务需求确定后，我一般是先后端再前端，毕竟大部分的业务逻辑都是在后端来处理，前端只负责呈现就好

画原型->设计表结构->开发 RestAPI 服务->接口测试->写前端->偶尔调整下接口和数据结构->完成。

数据库->前端->后端

@love 模拟数据啊

前端。前端数据格式先写死，后端直接提供格式类数据就行。

自己做项目 是公司的还是个人的？
如果是个人私活 那就前端先开始干，是公司的任务就从后端开始

我只是前端，我建议你先写前端，不仅页面能看到，还能通过 mock 去模拟数据，我想那样你后面写后端思路会更清晰，写起来更快

设计数据库，前端，定义接口，后端

设计数据库，画原型，设计 api，写前端，修 bug

比较喜欢原型设计先行，这样后端的存储结构基本就清晰了

@jakezh 真相了

按功能拆分, 后端前端交替进行

@canadahetian 一起写很累的。单纯写前台或者后台没那么累。。但的确能够第一时间发现问题，有时候前台写好了，后台发现这样做挺麻烦的，重写一下前台反而更简单，然后。。。[doge]

我反正先写后端, 前端写着写着就会想怎么更弄漂亮点.. 然后一直卡住..没有进度

我是先写前端，小数据扔文件里面，第二版本迭代写后端

一般先把前端架子弄起来，然后开始搞后端框架，后端接口定义，XXXX

自己的项目就像 GF，前前后后不都是随心情吗？

数据库规划好，然后前后端一起写，功能一个个加上去。

没有人说先写契约么？？？契约写好，前后端都可以同时开干了，契约如果能写好就代表业务模型已经 OK，所以如何建立数据库表也没问题了。

我是先写后端 虽然后面写前端的时候会发现很多问题

先写 API 文档

一般来说：
0 确认需求文档（有甲乙方的情况）。个人搞可以比较随意，直接开干
1 数据库 => 设计基础的数据逻辑
2 后端接口 => 基础接口，基础的 CRUD
3 前端页面，确认了 1 、2 大致逻辑就有了。搞页面、展示、交互
4 一步步细化功能，1 、2 、3 可能都会有调整

个人习惯是：先写个伪数据的生成器，然后搞前端，顺便理清数据结构。然后再去搞后端，来回磨合。

@wzw serverless 是绑定平台的，你用 Google Cloud 和 AWS 可能会用到不同的技术，尤其是 Nosql 数据库的 API 和设计思路不尽相同。先选一个平台吧。

@BruceWolf +1

一个人写前端，一个人写后端