V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  justdoit123  ›  全部回复第 2 页 / 共 18 页
回复总数  345
1  2  3  4  5  6  7  8  9  10 ... 18  
2025 年 9 月 23 日
回复了 ko20 创建的主题 汽车 好像一直没人讨论 byd 拿下全球最速汽车 496.22km/h 这件事
请加速进入 “水深火热”。
2025 年 9 月 23 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@qxmqh 我们现在是有业务开发的时候。尽量做一些清理工作。太多太多功能了,其实可以不要的。这些僵尸功能不清除,要合并单体也是够麻烦的。

我们核心的功能是个人数据同步、社区、会员三个业务模块。但是却附着大量产品经理们的“快速实验功能”。
2025 年 9 月 23 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@kuanat 非常感谢老哥的经历分享!

我们的 common 库(基本等于工具库)也有类似你说的不一致问题。

1. 改动不兼容。依赖的地方迁移不干净。后来要求,尽量不做不兼容改动。实在要兼容,旧的别动,写个新的。扩展到本主题的常量、DTO 代码,也是这样的道理。不过这种事情,就怕人偷懒。一偷懒,埋下运行时的雷。

2. 这个 common 库,在各个业务 repo 里是以 git tag 的形式进行版本依赖声明的。类似你说的 ”对应的 commit“。但是因为各种“时过境迁”的原因,大家不得不共用一个测试环境。测试环境的代码,经常是开发分支合并在一起的。还有很多细节没必要展开来说。 总之最终导致,这个 common 库的 git tag 不对,在测试环境未必会暴露出来。基建支撑不足的弊端就体现在这里了。现在只能用千叮咛万嘱咐的方式,告诉大家。改了 common ,第一时间去升级依赖。

后续把常量代码也迁移到 common 库后,这样的问题依然会发生。不过,总比现在会好一些。现在的维护心智负担更大。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@183shl 这个方案的阻力就在这里。

我们其实有一个 common 库,里面放了一堆 utils 、架构 base 之类的代码。之前的 leader 强调,这里面不允许放入任何业务逻辑相关的代码。所以以前常量也没放这里。

团队的人会觉得改这里面的代码,还要去升版本,很麻烦。

有时候就直接在业务 repo 里,也写个 xxx utils 。


我觉得你说的最后一句是有道理的,复用很强的再抽到 common 。这样就比较平衡。偶尔一两次的依赖,就直接抄一遍。依赖次数多了,再抽到 common 。很明显一定会被依赖很多次的,一开始就直接写 common 里。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@sampeng 几乎没有 code review 。

说得难听点,现在最好的 "code review" 就是测试 + 一上生产环境就挂掉。没埋雷,半夜爆炸就不错。

所以,我才想多引入一下非人工的花销来尽量保证稳定。比如:

1. type hint 。有点作用。
2. 写 DTO 而不是一个 dict 满天飞。不然回头维护的时候很慢热,记不住 key ,经常导致 KeyError 。也算有点作用。
3. 常量共享而不是用到就“手抄”一遍,这种手抄还会抄错。


不怕各位笑话。我们还有一个“运行时的常量共享方案”是这样的:每个服务提供一个接口返回本服务的一些常量定义,然后服务启动的时候,去请求一遍这些常量定义。 我感觉是很难用。运行时、纯动态,你写代码的时候,根本不知道自己引用的值存不存在。IDE 也无法给你补全。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@iyaozhen 微服务是既定现状,前人拆分的,至少已经快 8 年了,暂时没资源去改回单体。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
综合上面的回答,可能适合的方案还是服务的“常量”代码抽成一个包。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
monorepo 倒是也可以。但是我感觉组员有时候写得很野,跨服务乱引用。综合来看,不太适用我们。
2025 年 9 月 22 日
回复了 justdoit123 创建的主题 程序员 微服务之间,如何处理常量、DTO 冗余问题?
@Maboroshii grpc 可以上。但是需要共享的代码,不局限于 protobuf 描述的数据。
2025 年 9 月 18 日
回复了 michael2016 创建的主题 程序员 面试题:为什么 MySQL 不要使用 Docker 部署。。。。
容器一定是有额外开销的。对于这种有状态的服务。用普通的容器化方案能更快、更好的实现高可用与高稳定性吗?我感觉弊大于利。

抛开服务负载谈这些都是无效讨论。我感觉面试官没把问题问好。

另外,就算是大厂,也有小负载、低价值的服务。那么也就没必要什么服务都上岗上线,这时候直接使用 docker/k8s 搭建一个 mysql ,这才是务实的做法。
2025 年 9 月 18 日
回复了 0x93ee 创建的主题 小米 小米这改名 17 真的是 low 到家了
还有云台监控也是,也有小毛病。再高级的东西倒是没买过了。

智能插头、塔扇(这个塔扇真是没什么大用)倒是没什么问题。
2025 年 9 月 18 日
回复了 0x93ee 创建的主题 小米 小米这改名 17 真的是 low 到家了
@cmdOptionKana 我也不知道,还没试。

我买的扫地机器人、床头灯都有点小毛病。也是勉强能用。
2025 年 9 月 18 日
回复了 0x93ee 创建的主题 小米 小米这改名 17 真的是 low 到家了
同样家里一堆米家的产品。我用下来的感受是,入门最佳选择!

但是,不能当“传家宝”。也就自己在外租房,如果是自己家里,我可能会试试别的牌子的智能家居。
2025 年 9 月 17 日
回复了 Void000 创建的主题 生活 越来越多的 90/00 后开始断亲
@Cu635 这也是封建?

说白了就是适应经济形态变化而已。
2025 年 9 月 16 日
回复了 e13lau 创建的主题 程序员 忍不住要吐槽:钉钉 8.0 macOS 版本是一坨 X 贵司知道吗
“大公司都套壳了,我为什么不能?” 🐶
2025 年 8 月 26 日
回复了 EyebrowsWhite 创建的主题 程序员 Ansible 用起来好爽😄
@w568w 听起来不错,感谢分享!我个人真的讨厌 DSL ,用个工具就要学一个 DSL 。

所以在学习 Terraform 的时候,我就选择了 Pulumi 。像编程一样,写资源配置。

之前学 ansible ,怎么就没深入探索一下有没有其它方案。
2025 年 8 月 21 日
回复了 seWindows 创建的主题 Google 我体会到了悬挂指针的感觉
@winterbells 我是鸡蛋不放一个篮子里。

特别重要的账号的 MFA ,我会用另一个方案存储。Bitwarden 里只存密码。
2025 年 8 月 18 日
回复了 AjayEztt 创建的主题 Android 花粉、煤油给点建议?
家人送的 meta pro 40 一直用到现在,还很强劲。不过这一代的芯片还是代工的,属于被制裁前夕的芯片。

后来自己制作的芯片据说性能还没这一代的好。今年重新用回麒麟芯片的名字,不知道是不是已经炼成了。
2025 年 8 月 18 日
回复了 AjayEztt 创建的主题 Android 花粉、煤油给点建议?
如果不拍照,很多机型的 pro 版本都用不到。对比一下,主要是镜头提升,我感觉没必要。
1  2  3  4  5  6  7  8  9  10 ... 18  
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   877 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 22:09 · PVG 06:09 · LAX 15:09 · JFK 18:09
♥ Do have faith in what you're doing.