《飘》

112

做一些不严格要求准确度的事情，当前很快。

我不知道鼓吹 4 以上的人，参不参与实际的业务开发，尤其是 toB 、toG 的复杂业务系统，比如某央企的报账系统、财务系统、运维系统，一个复杂的功能涉及 N 多个场景，很多不同的条件，甚至与多个其他系统进行接口交互，你不盯着 AI 的结果进行 review 吗？

甚至这些系统都是运行了 7,8 年以上的，架构老旧，且充斥着 Map 传参，sql 拼接，没有注释，我到现在也只能借助 AI 先自己理解业务，找到在什么地方下手后再告诉 AI 怎么干，只能这样拆分成小的功能点再让 AI 参与，然后 review 结果。

你们真当这种大型业务系统的复杂度跟小猫补光灯一样简单啊

从来不否认 AI 的厉害，但是现在到处都是大言不惭鼓吹的，整的我都恍惚了。

还是说像我们这种非互联网行业，toB 业务软件开发的人话语权太低了。

49MHRYXLPMWH 已用谢谢

哥飞团伙？

https://i.imgur.com/Anjbodi.jpeg

1 个固定分支：

- **master**：主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护，不允许直接向该分支提交代码

3 个短期分支，完成功能开发之后需要删除：

- **feature/\***：功能分支。用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支
- **bugfix/\***：bug 修复分支。用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 master 分支，之后删除该分支
- **release/\***：发布分支。用于代码上线准备，该分支从 master 分支创建，创建之后发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支。release 分支可以长期保留

1 楼 @florentino 说的“本质就是通过 http 调用,至于你说的 VO,DTO 那些东西,可以放在 api 里面让其他服务依赖,也可以不放,调用方自己实现,反正最后都是会被序列化和反序列化的”

以及 4 楼 @123zouwen 说的“我觉得这是把单体思维代入到了微服务中. 分布式事务中间件个人觉得没有任何必要, 但很多 java 总希望能跟写单体服务一样直接 rpc 调用还能处理好事务.”

都非常对，是非常正确的微服务理念。基本上你从网上看到的绝大部分理论，都是指导你灵活使用，因为脱离了实际使用场景，并不会存在一个最佳实践。

而你困惑的地方在于，你没描述出来你们完整的工程场景，上面他们所说的都不足以解答你的疑惑，feign 用起来总是感觉有点不伦不类，对不对

我猜你是做 toB 的行业软件，业务逻辑复杂，功能点多，架构师又采用微服务形式，然后甚至一个功能模块一个微服务，从功能划分上倒是合理，但是呢，各模块之间的交付是很频繁及复杂的，互相调用的情况非常多， 硬套上微服务， 很难复用代码 & 控制事务， 如果各自解析 feign 的返回，还容易造成混乱（各种业务逻辑频繁变动、数据模型满天飞， 有些对象能有 200 多个属性）。

我是非常不建议也不喜欢大部分 toB 业务使用微服务开发的，不合适。

当然你们已经这么做了，我的建议是，各自模块的 DTO 、VO 、等 POJO ，自行维护。需要被其他模块调用的，复制一份 POJO 到 api 模块中，写好文档，做好代码同步即可。这样调用方不用关心如何解析，调用结果会自动转换为 POJO 对象，省心省事，又贴合单体应用的使用习惯。

有条件的话，还是从微服务的巨坑里爬出来吧。

@israinbow 这个小屏幕和支架能推荐一下吗？

过段时间再出个超级 vip

不止搜索难用，在收件箱下新建文件夹时，输入名称，回车，100%崩溃

堆屎山、维护屎山

mac 版打开即常驻菜单栏，能否增加一个开关，允许不在菜单栏显示&不常驻后台？

arco-design
https://arco.design/vue/docs/start

借楼，40 一位。请联系 vx：emh1eHVsdQ==