1 facebook47 1 天前 via Android 有个通用脚手架,为了方便扩展,只做最基本的功能就行了。可以看看 ems-admin |
![]() | 2 qiumaoyuan 1 天前 ![]() 自己写。用别人的只会节省前期的成本,而且这个“前期”不会太长。 |
![]() | 3 MIUIOS 1 天前 看项目需要,项目周期 |
![]() | 4 qiumaoyuan 1 天前 ![]() 因为前期需求不明确,或者需求很简单,看起来似乎什么现成的都能用。一方简单,一方复杂,简单的一方(需求)可以随便搭配复杂的开源项目。这往往是个甜美的陷阱。 但只要需求随便稍微复杂一些,跟开源项目设计思路不匹配,你就要开始跟这个现成的项目斗争,之后就是不断地内耗。 要么就选择将就,用自己的需求去将就开源项目,顺着开源项目的设计思路去改自己的需求。 |
5 tpxcer 1 天前 看情况如果有现成的,就用现成的自己喜欢架构的,方便修改。如果咩有那就自己写。 |
![]() | 6 hello333 OP @qiumaoyuan 关于 “但只要需求随便稍微复杂一些,跟开源项目设计思路不匹配,你就要开始跟这个现成的项目斗争,之后就是不断地内耗。 要么就选择将就,用自己的需求去将就开源项目,顺着开源项目的设计思路去改自己的需求。”。 大佬,方便举个例子吗? |
![]() | 7 hello333 OP @qiumaoyuan “而且这个“前期”不会太长。” 意思是到了后期会成为负担吗?具体体现在哪方面啊,方便讲一下么? |
![]() | 8 xiaoshan5733 1 天前 ![]() 我是从 0 写。网站、管理后台、api 服务、app 每个场景实现一个最佳模板,后续产品在此基础上迭代。 在有时间和有技术的前提下,根据自己的技术栈和功能规划调研技术框架,每个都亲自上手试一遍,哪个顺手用哪个。 |
9 lscho 1 天前 自己做了一个通用的管理后台基础框架,只包含通用功能,管理员、角色、权限、菜单 后续项目都从这个基础框架开始。 用别人的开源框架会存在不少问题,就是迭代更新不可控。 |
![]() | 10 yhxx 1 天前 自己写 别人的看不上,总是有各种各样的问题 自己几个月前写的也一样,过几个月就觉得都是辣鸡 |
![]() | 12 quejuwen 1 天前 ![]() ruoyi |
![]() | 13 Gilfoyle26 1 天前 看情况吧,如果是在企业里面,用通用的,否则会有巨大的沟通成本及学习成本 如果自己用,语言选自己喜欢的,版本最新的,技术最新的,完全拉满。 |
14 newtype0092 1 天前 不存在从 0 开始吧。 跟攒电脑一样,要么买品牌整机,要么买品牌散件组装,从 0 开始难道你自己还能手搓 CPU 和闪存颗粒吗。。。 |
![]() | 15 darkengine 1 天前 找个 Skeleton 项目开始写 |
16 left7410 1 天前 自己写的未必有开源框架的好,具体看业务复杂度还有是否有个性化需求吧 |
![]() | 17 clemente 1 天前 一次性的项目 就找框架搭 自己长期迭代的还是自己手写吧... |
![]() | 18 Ketteiron 1 天前 第一次用别人的,第二次就可以开始自己手搓一个了,不然没办法理解别人为什么要这么写,优点与缺点在哪。 |
19 nananqujava 1 天前 我用的 ruoyi-pro |
20 geying 1 天前 看项目周期 我干活基本逻辑是 如果是简单的项目 直接 ruoyi 一把梭 如果是开源项目改的话看是否能满足 80%以上的需求 如果可以就在原来的基础上改 项目结构,语法都延续 如果是长期项目我都从头开始搭,活基本上 AI 干,在这个基础上自己抽个脚手架 以后就可以沿用了 |
![]() | 21 qiumaoyuan 1 天前 @hello333 就是总结下来的一些经验,具体的例子一时想不出来了。有时候我就记着个结论,具体案例不太记着。 不过你可以拿我们的对话去问 DeepSeek 或者 ChatGPT ,我说得比较概括,AI 应该会解释得比较清楚。 但这种事情有点像小马过河,别人的经验总是别人的,你最多只能选择相信或者不相信,只有自己尝试过之后,那个“相信”才会变成“知道”。 |
![]() | 22 hello333 OP @qiumaoyuan 好的好的,感谢。 |
23 soulflysimple123 1 天前 看具体要求,比如说有工作流要求,支持复杂人员配置,支持转交,委托,多人会签之类各种操作,基本不可能自己从 0 写 |
![]() | 24 BNineCoding 1 天前 有 ai 之后,基本都用脚手架可以写,会方便很多。 |
![]() | 25 liyafe1997 1 天前 现在有 AI 了,直接从 0 开始,写 Prompt 让 AI 起项目 |
26 mx2dream 23 小时 28 分钟前 刚刚经历的自己的小项目,根据开源框架魔改,改到后面发现堆成了屎山,各种报错。身心俱疲之下只能重新从 0 开始,先做出一个最小可行的东西出来,后面再迭代,这样才舒服了许多 |
![]() | 27 jiayouzl 20 小时 5 分钟前 有 AI 了,后台我都 0 开始写了,之前用通用框架是图方便而已,通用框架掺渣了很多我不需要的功能,我又有强迫症不需要的功能压根就不想它显示出来,这点通用框架做不到的,除非魔改那还不如从 0 开始写呢。AI 几乎能完成 90%的后台任务了~ |
28 CoderLife 19 小时 13 分钟前 基于别的框架 然后封装 |
![]() | 29 darkway 19 小时 11 分钟前 好帖子,很有道理,收藏 |
![]() | 30 sk217 11 小时 18 分钟前 ![]() 主要是看项目方需求,能不能聊,能不能好好聊,有些东西是可做也可以不做的, 像你用了脚手架,它把角色跟权限还有用户体系都写死了,这个时候人家要加一套部门组织架构体系,嵌入到这一套权限体系里面来,还要求你权限跟着部门走,这个时候你就要重写一些已有代码,最后反而成本更高,还要你要去认真阅读人家的权限体系跟表结构关系,最后的开发成本比你从头开发 成本更高。 这些事情在十数年的开发工作中遇到的太多了,把新功能嵌入一套已有的代码体系里面,常常比从新撸一套的成本还高,过往的屎山代码不能动,因为多次测试后,一般屎山都很稳了,动了说不定就炸你身上,新的需求也要往里加,那就只能再加一层间隔层进行打补丁的操作 这也是为什么程序员不喜欢低代码,因为低代码进行了过度的封装,这些封装本身就是不必要的封装,也许它快速解决了你日常 99%的需求,最后你发现日常 1%的需求 需要你花 99%的时间去解决,最后就本末倒置了,像一些 vue3 组件没有提供足够的客制化功能,最后你还要通过 vdeep 去解决,最后搞不定,还得把人家框架源代码撸过来自己再定制一番。 软件工程最大的问题就是它的易修改性,每个人都希望它进行变化,进行迭代,建房子你不会打好地基了,然后再要求修改承重扛地震设计,拼积木你不会要求积木拼完了,再重新拆改给每个积木的四个角再打磨光滑一点,别划拉到手了,这需要重新开模模具,然后进行注塑,包装送到你手上,进行重新拼凑,而在软件开发中,唯一可以确定的就是变化是随机的,且需求方随时都在变 |
![]() | 31 Genshin2020 8 小时 52 分钟前 自己封装的,而且封装的很基础,甚至 UI 库都没有,因为你也不知道用户要求用什么 UI 库。 |
![]() | 32 xuanbg 8 小时 13 分钟前 当然是自己搞一个可复用的框架啊 |
![]() | 33 Yanlongli 7 小时 57 分钟前 大部分是从 0 开始“组装”,基础框架+第三方组件+魔改第三方组件+一些自己的组件 |
![]() | 34 raphaelsoul 7 小时 41 分钟前 现在有 ai 了 从头写也挺快的 国庆 7 天冲刺了一个使用数字货币的 telegram 虚拟物品交易机器人 |
35 way2create 6 小时 19 分钟前 看情况咯,但一般不会去找个什么开源商城之类去二开,那种开发体验一坨,总之就是看工期结合实际情况能完成工作要求的情况下怎么舒服怎么来。 |
36 kakki 4 小时 56 分钟前 看代码,改代码比写代码难度要高 |