V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zhuwd
V2EX  ›  程序员

自己做项目,一般是先写前端还是后端?

  •  
  •   zhuwd · 2020-04-12 21:25:44 +08:00 via iPhone · 16864 次点击
    这是一个创建于 1684 天前的主题,其中的信息可能已经有所发展或是发生改变。

    新入行的小白,想问一下前辈们,如果自己一个人负责前后端,一般是先把页面按照产品原型写完,然后根据页面需要的数据写后台接口,还是先根据大体得功能模块写出接口,再由前端覆盖每个接口功能呢

    77 条回复    2020-04-14 10:13:34 +08:00
    MuscleOf2016
        1
    MuscleOf2016  
       2020-04-12 21:27:41 +08:00   ❤️ 6
    你是不是有活,可以外包出来,锻炼下自己项目管理 [手动狗头]
    wormcy
        2
    wormcy  
       2020-04-12 21:28:29 +08:00
    我一般先写前端
    hackxing
        3
    hackxing  
       2020-04-12 21:29:49 +08:00
    我一般都是 先根据原型整理一下功能,后端先行,然后前端展示数据...
    whypool
        4
    whypool  
       2020-04-12 21:33:59 +08:00
    先前端,毕竟看得到
    liuzhiyong
        5
    liuzhiyong  
       2020-04-12 21:39:31 +08:00   ❤️ 1
    肯定先前端,因为这个立刻能看见。
    elfive
        6
    elfive  
       2020-04-12 21:43:26 +08:00 via iPhone
    我不是写前后端的,主要写 C/C++驱动那块的东西。不过最近公司需要写个网页能用的管理平台,公司只有我业余时间写过(我也是个前后端的半吊子)。
    我是先写的前端,然后可以根据前端的设计来制定接口,免得写了后端之后,接口设计不合理导致需要重新设计接口和数据库的尴尬。
    ajax10086
        7
    ajax10086  
       2020-04-12 21:48:45 +08:00
    先前端吧,客户问进度的时候可以给他看
    wuhanchu
        8
    wuhanchu  
       2020-04-12 21:49:07 +08:00 via iPad
    先设计数据库
    jakezh
        9
    jakezh  
       2020-04-12 21:51:55 +08:00 via iPhone
    数据库->后端->前端->后端->前端->后端->前端->后端->前端->后端->前端…………
    cmdOptionKana
        10
    cmdOptionKana  
       2020-04-12 21:52:25 +08:00   ❤️ 5
    真的写代码的时候,最好是先写数据库 schema (或 model ),这个才是整个项目的核心,同时也是后续修改起来比较麻烦的地方,会想尽量减少修改次数。

    把数据库 schema (或 model )思考得非常清楚的时候,在脑子里就有整个项目非常清晰的骨骼,剩下就是后端围绕数据库做增删改查和前端美化。
    noobma
        11
    noobma  
       2020-04-12 21:53:27 +08:00
    不喜欢写界面,所有先写前端,前端写完能长舒一口气😂
    lewinlan
        12
    lewinlan  
       2020-04-12 22:19:48 +08:00 via Android
    作为后端程序员,习惯先后端搭个架子,这样才会感觉思路有个主线。然后围绕需求,先前端再后端。
    前端方便展示进度也是一个很重要的因素。
    go 比 js 开发效率高也是。
    BruceWolf
        13
    BruceWolf  
       2020-04-12 22:20:26 +08:00   ❤️ 6
    一人独揽的话,先前端,能更高效的确定所需要的数据,然后才是完成数据库表设计,最后是业务逻辑,接口的输入输出是什么。

    通俗的说,确定数据流的终点在哪,起点在哪,最后设计具体路线。
    canadahetian
        14
    canadahetian  
       2020-04-12 22:58:53 +08:00   ❤️ 1
    一起不香吗?
    yjxjn
        15
    yjxjn  
       2020-04-12 23:01:22 +08:00 via Android   ❤️ 1
    公司项目,先画原型 UI,然后设计数据库,然后写后端,然后写前端。
    murmur
        16
    murmur  
       2020-04-12 23:09:35 +08:00
    先出需求分析和原型啊
    xiaoidea
        17
    xiaoidea  
       2020-04-13 00:04:22 +08:00
    数据库设计 -> 接口定义 -> 前端 -> 后端
    rogwan
        18
    rogwan  
       2020-04-13 00:21:44 +08:00
    工具类的先写前端问题不大,需要保存大量用户数据的,做之前反复推敲数据表设计,这是基石。后期迭代过程中,最危险的就是增删用户表、迁移用户数据。生产机上的数据变迁那是边开飞机边维修的活,前期设计不合理,容易机毁人亡。前端的内容,随便怎么迭代,影响限于颜值范围,不破坏数据的回滚也容易。
    xcstream
        19
    xcstream  
       2020-04-13 00:30:32 +08:00
    一个一个功能写
    magiclz233
        20
    magiclz233  
       2020-04-13 00:34:27 +08:00
    先搞清楚需求,把数据库和原型搞出来 然后照着来就行了
    mumbler
        21
    mumbler  
       2020-04-13 02:33:11 +08:00 via Android
    必须先做前端

    理由:个人开发不会去做需求分析,画原型图什么的,思考不一定很全面。先做前端的好处是相当于系统性思考了,不要后端也能出个 demo 先把玩一下,感觉不好地方及时修改,才知道需要后端那些接口
    lihongming
        22
    lihongming  
       2020-04-13 03:00:53 +08:00 via iPhone
    用什么平台也很关键。

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

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

    其中最主要的变化有两点:一是数据库设计后移,这是 DynamoDB 的特点决定的;二是前端开发提前了,因为 React 开发会用到大量的开源组件,这些组件对数据源格式的要求不尽相同,先做这些可以更好的设计 API,减少对数据的二次加工。
    dodo2012
        23
    dodo2012  
       2020-04-13 03:20:27 +08:00
    数据库设计,api,前端
    wzw
        24
    wzw  
       2020-04-13 03:38:15 +08:00 via iPhone
    @lihongming 一直是传统开发,我是不是要看看学学 serverless 了,区别很大?
    kaiki
        25
    kaiki  
       2020-04-13 07:04:16 +08:00
    先写后端完全摸瞎,以前是看心情写,后来是先写前端了。
    love
        26
    love  
       2020-04-13 08:06:27 +08:00 via Android
    很明显要先写后端,至少写到能输出前端需要的基本数据,然后前后端一起进化。先写前端数据哪里来的?
    gaodeng
        27
    gaodeng  
       2020-04-13 08:21:17 +08:00
    自己一个人一把梭,还分什么先后,当然是一边写前端,一边写后端啊。
    shakoon
        28
    shakoon  
       2020-04-13 08:25:58 +08:00
    一个人的话,分啥前后端啊,一锅端了
    handsomehaitao
        29
    handsomehaitao  
       2020-04-13 08:48:07 +08:00
    @jakezh 真实
    DOLLOR
        30
    DOLLOR  
       2020-04-13 09:03:24 +08:00
    @love 当然是用假数据了。简单的用*.json 和*.xml ,高级点的用 mock.js 。
    BarZu
        31
    BarZu  
       2020-04-13 09:07:01 +08:00
    9 楼正解
    CzaOrz
        32
    CzaOrz  
       2020-04-13 09:07:54 +08:00
    我一般是先想好要实现的功能,然后定好大致的数据结构
    先写后端传输假数据,再开始搞前端,配合着改后端。。

    因为这个过程中,你会慢慢发现很多功能实现不了,然后慢慢的阉割.....
    xmge
        33
    xmge  
       2020-04-13 09:09:17 +08:00
    1 、设计功能
    2 、设计数据库
    3 、定义接口
    4 、写后端然后前端
    Desiree
        34
    Desiree  
       2020-04-13 09:17:42 +08:00
    做项目都是按功能需求来得啊,哪有想到哪做哪得。功能模块-> 前端布局(模拟数据) -> 后端接口。这样应该是比较舒服的把
    NotFoundEgg
        35
    NotFoundEgg  
       2020-04-13 09:19:21 +08:00
    设计表->功能 A->前(mock)->后->功能 B->前->后。。。
    对于每个相对独立的功能 /模块的开发周期内 是同时包含了前和后的
    securityCoding
        36
    securityCoding  
       2020-04-13 09:19:25 +08:00
    @love mock 一下就行了呗
    taxiaohaohhh
        37
    taxiaohaohhh  
       2020-04-13 09:22:27 +08:00 via Android
    先前端,前端下来不用整理一眼就能看清结构
    xinxing260
        38
    xinxing260  
       2020-04-13 09:25:10 +08:00   ❤️ 1
    画原型 --> 创建 json 的 mock 数据 --> 前端 --> 根据 json 文件生成建表 sql --> 后端 --> 调试
    cwjokaka
        39
    cwjokaka  
       2020-04-13 09:26:17 +08:00
    先前端,因为前端就是测试(狗头),这样就有测试驱动的模样了(再次狗头)
    pumily
        40
    pumily  
       2020-04-13 09:32:02 +08:00
    个人感觉是前端先行吧,说白了后端的接口就是为了前端信息展示提供服务的。在你先写前端时,能够比较容易的加深你对产品和需求的理解,知道你需要个什么样的接口,这样在你后前编写起来前端时就能得心应手的。
    skys215
        41
    skys215  
       2020-04-13 09:35:44 +08:00
    我后端,表示先写后端。因为先写前端的话要 mock 数据。先写后端的话不用 mock 。
    swulling
        42
    swulling  
       2020-04-13 09:37:01 +08:00 via iPhone
    先写 api
    Vegetable
        43
    Vegetable  
       2020-04-13 09:37:05 +08:00
    先数据表
    再接口
    然后随意,一般前端开始吧,毕竟调接口文档比调接口简单.
    l890908
        44
    l890908  
       2020-04-13 09:58:57 +08:00
    怎么可能是先前端?肯定是数据表规划好,数据结构不清楚,怎么写前端?
    thet
        45
    thet  
       2020-04-13 10:00:37 +08:00
    先摸清需求,然后出原型,设计数据库,后端,再前端,代码不用着急写的
    Ascotbe
        46
    Ascotbe  
       2020-04-13 10:01:59 +08:00
    菜鸡的我先后端,然后在前端,不然数据交互有点懵
    liuxey
        47
    liuxey  
       2020-04-13 10:05:19 +08:00
    主要看思维模式,如果想的通透,哪里开始都一样
    varrily
        48
    varrily  
       2020-04-13 10:06:59 +08:00
    先画图,架构图,流程图,ER 图,再写后端,单测,再前端。

    自己的项目,即便再省,ER 图,单测最好别省。
    guolaopi
        49
    guolaopi  
       2020-04-13 10:12:20 +08:00
    先写后端,先写前端最后可能会发现项目一多半的时间都在折腾前端,包括但不限于 CSS 、组件选择、等打包。。
    Les1ie
        50
    Les1ie  
       2020-04-13 10:22:45 +08:00
    后端未动,前端先行。写死链接,能用就灵。
    csusong
        51
    csusong  
       2020-04-13 10:25:43 +08:00
    先画页面,再设计数据格式,再写前端。
    hippieZhou
        52
    hippieZhou  
       2020-04-13 10:27:30 +08:00
    原型和业务需求确定后,我一般是先后端再前端,毕竟大部分的业务逻辑都是在后端来处理,前端只负责呈现就好
    xuanbg
        53
    xuanbg  
       2020-04-13 10:33:48 +08:00
    画原型->设计表结构->开发 RestAPI 服务->接口测试->写前端->偶尔调整下接口和数据结构->完成。
    CantSee
        54
    CantSee  
       2020-04-13 10:45:50 +08:00
    数据库->前端->后端
    enrio
        55
    enrio  
       2020-04-13 10:51:42 +08:00
    @love 模拟数据啊
    dizun
        56
    dizun  
       2020-04-13 10:52:22 +08:00 via Android
    前端。前端数据格式先写死,后端直接提供格式类数据就行。
    bsg1992
        57
    bsg1992  
       2020-04-13 10:56:58 +08:00
    自己做项目 是公司的还是个人的?
    如果是个人私活 那就前端先开始干,是公司的任务就从后端开始
    SSW
        58
    SSW  
       2020-04-13 10:57:55 +08:00
    我只是前端,我建议你先写前端,不仅页面能看到,还能通过 mock 去模拟数据,我想那样你后面写后端思路会更清晰,写起来更快
    prolic
        59
    prolic  
       2020-04-13 10:59:17 +08:00
    设计数据库,前端,定义接口,后端
    cccRaim
        60
    cccRaim  
       2020-04-13 11:19:53 +08:00
    设计数据库,画原型,设计 api,写前端,修 bug
    jorneyr
        61
    jorneyr  
       2020-04-13 11:41:38 +08:00
    比较喜欢原型设计先行,这样后端的存储结构基本就清晰了
    wozhizui
        62
    wozhizui  
       2020-04-13 12:05:03 +08:00
    @jakezh 真相了
    spongebobsun
        63
    spongebobsun  
       2020-04-13 12:08:04 +08:00
    按功能拆分, 后端前端交替进行
    mostkia
        64
    mostkia  
       2020-04-13 12:19:00 +08:00
    @canadahetian 一起写很累的。单纯写前台或者后台没那么累。。但的确能够第一时间发现问题,有时候前台写好了,后台发现这样做挺麻烦的,重写一下前台反而更简单,然后。。。[doge]
    edk24
        65
    edk24  
       2020-04-13 13:20:50 +08:00   ❤️ 2
    我反正先写后端, 前端写着写着就会想怎么更弄漂亮点.. 然后一直卡住..没有进度
    cz5424
        66
    cz5424  
       2020-04-13 13:30:32 +08:00 via iPhone
    我是先写前端,小数据扔文件里面,第二版本迭代写后端
    alexmy
        67
    alexmy  
       2020-04-13 14:11:33 +08:00
    一般先把前端架子弄起来,然后开始搞后端框架,后端接口定义,XXXX
    pomelotea2009
        68
    pomelotea2009  
       2020-04-13 14:25:34 +08:00 via Android
    自己的项目就像 GF,前前后后不都是随心情吗?
    loading
        69
    loading  
       2020-04-13 14:45:24 +08:00 via Android
    数据库规划好,然后前后端一起写,功能一个个加上去。
    a194259440
        70
    a194259440  
       2020-04-13 14:56:40 +08:00
    没有人说先写契约么???契约写好,前后端都可以同时开干了,契约如果能写好就代表业务模型已经 OK,所以如何建立数据库表也没问题了。
    Yuicon
        71
    Yuicon  
       2020-04-13 15:34:34 +08:00
    我是先写后端 虽然后面写前端的时候会发现很多问题
    LokiSharp
        72
    LokiSharp  
       2020-04-13 15:57:00 +08:00 via iPhone
    先写 API 文档
    VickStarKii
        73
    VickStarKii  
       2020-04-13 18:30:18 +08:00
    一般来说:
    0 确认需求文档(有甲乙方的情况)。个人搞可以比较随意,直接开干
    1 数据库 => 设计基础的数据逻辑
    2 后端接口 => 基础接口,基础的 CRUD
    3 前端页面,确认了 1 、2 大致逻辑就有了。搞页面、展示、交互
    4 一步步细化功能,1 、2 、3 可能都会有调整
    JCZ2MkKb5S8ZX9pq
        74
    JCZ2MkKb5S8ZX9pq  
       2020-04-13 18:45:59 +08:00
    个人习惯是:先写个伪数据的生成器,然后搞前端,顺便理清数据结构。然后再去搞后端,来回磨合。
    lihongming
        75
    lihongming  
       2020-04-14 03:48:57 +08:00 via iPhone
    @wzw serverless 是绑定平台的,你用 Google Cloud 和 AWS 可能会用到不同的技术,尤其是 Nosql 数据库的 API 和设计思路不尽相同。先选一个平台吧。
    ericgui
        76
    ericgui  
       2020-04-14 07:32:59 +08:00
    zc1249274251
        77
    zc1249274251  
       2020-04-14 10:13:34 +08:00
    一个人写前端,一个人写后端
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3496 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 10:26 · PVG 18:26 · LAX 02:26 · JFK 05:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.