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

[转] 最近公司在用 Java 重写一个 ruby on rails 应用,我的一些碎碎念。

  •  
  •   janxin · 2020-11-02 16:39:30 +08:00 · 5615 次点击
    这是一个创建于 607 天前的主题,其中的信息可能已经有所发展或是发生改变。

    转载自 https://ruby-china.org/topics/40526

    最近的工作本质上是公司收购了一个海外的创业公司,然后用 java 重写一个 ror 应用。
    
    然后。。诡异的事发生了。。
    
    原代码库目测大约 5-6 个 ruby 程序员的 code base,做微服务架构后,拆分成 5-6 个领域,一个团队 4-5 个 java 程序员。
    
    阿里的大中台小前台概念火了,于是有前台团队做业务,中台团队提供 crud,再来个前端团队,约 80 人,这就算齐活了。
    
    于是整件事朝着魔幻的方向演进了:
    
    由于分布式监控做的不到位,一些同学花很多时间排查线上问题
    过早使用分库分表,而且使用姿势不当,接口 SLA 出问题了
    中台这边的一个本能是 “考虑通用性”,建模有大量过度设计,于是接口性能出问题了,一些同学玩命优化接口性能
    没人说得清楚前台和中台究竟是什么,于是边界划分开始撕逼了,中台说要考虑通用,前台说这个系统不属于中台能力,花了大量时间在需求讨论上
    划分不清楚,于是架构师来了,天天在处理域和域之间的划分问题,中台前台的划分问题;其实角色有点像劝架大妈
    渐渐地,大家变得忙起来了。。。老板觉得流程需要标准化起来,需求要从前台产品经理流到中台产品经理,开发只根据中台产品经理 “提炼” 出来的需求进行开发,于是大家更忙了。。
    
    在这个过程中,很多人的生产力已经被消磨殆尽。大家开始 996,白天各种开会拉群,晚上干活。但是看各个部门的老板的 ppt,一点不含糊: 通用能力服务各个业务场景、功能可以灵活拼装、定义标准能力、赋能业务。 各种描述都齐活。
    
    但回到问题本身。这家公司,原来只是一个只有二十几个,甚至几个人干起来的产品,一个单体应用可以创造一个估值几百万的公司,我是感觉被降维打击了。
    
    去大厂感受摩擦力;去小厂感受生产力。想起来已经 4 个年头没有做 rails 开发,最近突然遇到 rails 实打实的生产力的降维打击(尽管语言因素可能只占部分)。有点感慨。现在看来,普通的 web 应用,rails 还是将程序员的代码直接转化为生产力和产品力的大杀器。
    
    51 条回复    2020-11-03 18:37:57 +08:00
    chendy
        1
    chendy  
       2020-11-02 16:54:53 +08:00   ❤️ 11
    强行拆微服务、强行搞中台是这样的
    都是大厂架构师吹逼的东西,没场景没能力看个乐就行,谁上谁那啥…
    dk7952638
        2
    dk7952638  
       2020-11-02 17:00:59 +08:00
    首先这肯定夸张的成分比较大,吹 ROR 是真的
    对于国内大厂来说,招聘 10 个 Java 比招聘 10 个 Ruby 要简单太多,而且 Java 明显可以更好的压榨生产力
    echo1937
        3
    echo1937  
       2020-11-02 17:09:18 +08:00
    就算以前是 Spring 一把梭的,按文中的改法也照样出问题。

    强行微服务,强行中台就是这样子的,一路趟坑。
    acmore
        4
    acmore  
       2020-11-02 17:13:41 +08:00
    之前的一个评论在在这再贴一下:

    > 其实确实没有必要为了微服务而微服务,虽然有很多理论指导和论证,但是真正应用的时候大多都是趟泥地。当拆分> 的好处远大于不拆分的坏处时自然就会拆分,而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 > Monolith 或者至少是有演化成为 Monolith 的趋势,这个时候开始制定拆分策略应该是比较合适的,很多项目大概都活> 不到这个时候。当然大多数时候都是拍板者拍板,干活的执行。

    表面是 Overdesigning, 实质是 KPI Oriented Programming.
    acmore
        5
    acmore  
       2020-11-02 17:14:28 +08:00   ❤️ 1
    @acmore 格式乱了。

    没有必要为了微服务而微服务,虽然有很多理论指导和论证,但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分,而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势,这个时候开始制定拆分策略应该是比较合适的,很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板,干活的执行。

    表面是 Overdesigning, 实质是 KPI Oriented Programming.
    Rwing
        6
    Rwing  
       2020-11-02 17:16:48 +08:00   ❤️ 1
    java 是这样的……我这也有一个案例,一个 C#的项目,原本 1.5 个人好好的,然后某个大佬心血来潮说要 java 重构,业务规模没变,现在要 7-8 个人忙前忙后……
    acmore
        7
    acmore  
       2020-11-02 17:20:27 +08:00
    @Rwing Java 相比 C# 确实会啰嗦很多,但不至于差别这么大,估计是用了体量不对等的框架和设计理念吧。大事有大框架,小事有小框架或者不用框架,而在人们写 Java 时习惯性地都用大框架(包括我自己)。
    cmdOptionKana
        8
    cmdOptionKana  
       2020-11-02 17:23:44 +08:00
    但是 ruby 性能真的差啊,业务发展起来之后重写成别的语言也很正常。最主要的问题可能是缺少一个擅长 Java 的 CTO,才导致各种问题。
    zhuangzhuang1988
        9
    zhuangzhuang1988  
       2020-11-02 17:26:17 +08:00   ❤️ 1
    KuroNekoFan
        10
    KuroNekoFan  
       2020-11-02 17:27:10 +08:00   ❤️ 1
    用 java 就是容易把简单的事情弄复杂,that's it
    acmore
        11
    acmore  
       2020-11-02 17:29:07 +08:00
    @zhuangzhuang1988 我是同意的,毕竟我司出品。
    BBCCBB
        12
    BBCCBB  
       2020-11-02 17:59:55 +08:00   ❤️ 1
    这和 java 还是 ror 没啥关系,, 主要是你们拆拆拆, 过度设计了吧??
    zhuangzhuang1988
        13
    zhuangzhuang1988  
       2020-11-02 18:07:21 +08:00
    @acmore 微软牛逼
    gowk
        14
    gowk  
       2020-11-02 18:12:46 +08:00 via Android   ❤️ 5
    “中台,我信了你的邪” https://36kr.com/p/1725013082113
    这篇文章不错,一个字一个字的看完了
    jones2000
        15
    jones2000  
       2020-11-02 18:59:21 +08:00   ❤️ 3
    说实话, 有活干,管他干什么呢, 工资照发不就可以了。 亏的都是投资人的钱, 爱怎么重写就怎么重写, 给足加班费就可以。 钱烧完了, 换一家。简历也好看,重构,微服务,中后台等等概念都有了。
    WispZhan
        16
    WispZhan  
       2020-11-02 19:51:06 +08:00
    最讨厌那种半吊子架构师。 啥都不知道就夏几把推微服务、拆微服务的。另外不会写代码的架构都是水货,有的架构是会写代码但是没时间写,有的是写都不会写就莫名其妙的是架构了。
    hoyixi
        17
    hoyixi  
       2020-11-02 19:54:51 +08:00   ❤️ 1
    很多时候搞事,不是为了事本身。人员重组,重立山头,立威望,分权力,抢话语权,这才是那些管理层关心的。
    back0893
        18
    back0893  
       2020-11-02 20:01:45 +08:00
    为了拆分而拆分...
    nnws2681521
        19
    nnws2681521  
       2020-11-02 20:06:54 +08:00
    不就一个网页吗,搞那么多英文装逼吗
    EminemW
        20
    EminemW  
       2020-11-02 21:54:32 +08:00
    这关 java 什么事,这明显是架构设计问题
    Cbdy
        21
    Cbdy  
       2020-11-02 23:15:20 +08:00 via Android   ❤️ 1
    java 社区过度设计确实挺厉害,混子可能也相对其他技术栈多一些,我也贴一篇文章
    https://yuheng.io/articles/i-hate-java
    impl
        22
    impl  
       2020-11-02 23:35:22 +08:00
    阿里巴巴董事长兼 CEO 张勇在湖畔大学分享时也说:如果一个企业奔着中台做中台,就是死。
    --- 划重点,要考
    xuanbg
        23
    xuanbg  
       2020-11-03 00:07:34 +08:00
    @cmdOptionKana 不不不,擅长 Java 并没有什么卵用。 @KuroNekoFan 这也不是什么语言的锅,只是没有找到正确的方法而已。

    楼主的问题是没有人去把整个系统的结构梳理清楚,导致各项目搞不清楚自己的定位,和别的项目是一个什么关系。大家都按着自己的惯性思维去做事,没有纲领,也没人负责协调,出现冲突很正常,没有冲突反而不正常。

    这种情况下搞微服务只是把单体架构掩盖的问题给暴露了出来而已。当然你要说没有暴露出来的问题就不是问题我也没法反驳的说🐶
    kkbblzq
        24
    kkbblzq  
       2020-11-03 00:18:31 +08:00
    真就为了设计而设计了,这玩意需要有比较多实际的业务沉淀的吧。就一个项目而且还是买来的,整中台纯属领导脑补出来的需求吧
    haohappy
        25
    haohappy  
       2020-11-03 01:13:20 +08:00
    就这样工资才能起来哈
    gowk
        26
    gowk  
       2020-11-03 06:55:04 +08:00 via Android
    @jones2000 哈哈哈,兄弟你看的开,确实就是这么个理儿,没必要自寻烦恼
    lrh3321
        27
    lrh3321  
       2020-11-03 08:22:43 +08:00 via Android
    多创造了 70 多个岗位
    l00t
        28
    l00t  
       2020-11-03 08:58:10 +08:00
    大厂创造工作岗位。

    花的是老板的钱,积累的是自己的技术和经验,多好。
    drackzy
        29
    drackzy  
       2020-11-03 09:02:07 +08:00
    Ruby 国内很少有人用了,薪资不行没有大厂。写 Java 大厂校招都 22 、24K 了。
    Zatoichi1966
        30
    Zatoichi1966  
       2020-11-03 09:05:50 +08:00
    说实话现在大部分公司不都是搞分布式 微服务吗,感觉是你们的经验不足,搞得这么乱,,,
    Zatoichi1966
        31
    Zatoichi1966  
       2020-11-03 09:08:13 +08:00
    说实话现在大部分公司不都是搞分布式 微服务吗,感觉是原文作者的公司经验不足,搞得这么乱,,,
    Zatoichi1966
        32
    Zatoichi1966  
       2020-11-03 09:11:24 +08:00
    @WispZhan 确实
    coolair
        33
    coolair  
       2020-11-03 09:15:33 +08:00
    中台到底是个啥玩意?!
    passerbytiny
        34
    passerbytiny  
       2020-11-03 09:21:25 +08:00 via Android
    就算是扩容后的团队,也才 80 个人,这点规模,拆个狗屁的中台。
    cmdOptionKana
        35
    cmdOptionKana  
       2020-11-03 09:43:50 +08:00 via Android
    @xuanbg 也就是说 CTO 水平不行,要么就是故意花公司钱积累经验。总觉得不能怪 Java
    lbp0200
        36
    lbp0200  
       2020-11-03 10:28:08 +08:00 via iPhone
    国内通病
    limboMu
        37
    limboMu  
       2020-11-03 10:38:16 +08:00
    其实真正有用的是 DDD,服务拆不拆没啥关系,忙前忙后瞎 JB 搞又不懂的人很多
    molika
        38
    molika  
       2020-11-03 10:51:23 +08:00
    喜乐见闻
    zencoding
        39
    zencoding  
       2020-11-03 11:20:10 +08:00
    楼主文字能力不错,再现那个我好熟悉的一幕幕哈哈
    lbp0200
        40
    lbp0200  
       2020-11-03 11:28:44 +08:00
    不然那些创业失败,最终负债几百万的人,是怎么来的???
    neocanable
        41
    neocanable  
       2020-11-03 11:33:01 +08:00
    我是个 ruby 程序员,不得不说,做东西确实快,但是随之而来的问题也多。
    但是你让我用 java 去重构一个 ror 写的服务,还是有点儿肝儿颤的
    lonelymarried
        42
    lonelymarried  
       2020-11-03 11:34:40 +08:00
    我一个搞 frontend 的,都知道中台了。
    xuanbg
        43
    xuanbg  
       2020-11-03 11:49:42 +08:00
    @coolair 我理解的中台就是把业务中可抽象为通用能力的部分单独抽取出来,做成一个或多个独立的、不依赖业务的服务。
    woshiaha
        44
    woshiaha  
       2020-11-03 12:00:37 +08:00
    中台这种东西应该是在业务迭代中逐渐演变出来的 而不是上来直接设计划分出来的
    Kirsk
        45
    Kirsk  
       2020-11-03 12:34:08 +08:00 via Android
    这锅 Java 不背 人的问题
    danhahaha
        46
    danhahaha  
       2020-11-03 12:34:35 +08:00   ❤️ 2
    以后多几个这种公司,可以解决广大程序员朋友的就业问题。
    java 的用 C 重构
    C 的用 go 重构
    go 的改 php

    中台微服务大数据各种新名词一起上,共同推动 gdp
    axex
        47
    axex  
       2020-11-03 13:03:37 +08:00
    这种应该一步步把之前的某个模块拆出来做一个微服务
    blless
        48
    blless  
       2020-11-03 13:04:14 +08:00 via Android
    go 改 php 还真没听过,倒是一堆 php 转 go 的
    @danhahaha
    coolmenu
        49
    coolmenu  
       2020-11-03 14:41:40 +08:00
    @blless go 应该改 rust
    LessonOne
        50
    LessonOne  
       2020-11-03 16:10:33 +08:00
    @danhahaha good job
    yeahvov
        51
    yeahvov  
       2020-11-03 18:37:57 +08:00
    相反 最近 Java 转 ror 了
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2343 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 05:35 · PVG 13:35 · LAX 22:35 · JFK 01:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.