lvlongxiang199 最近的时间轴更新
lvlongxiang199

lvlongxiang199

V2EX 第 296454 号会员,加入于 2018-03-04 16:36:39 +08:00
lvlongxiang199 最近回复了
8 天前
回复了 xhwdy26 创建的主题 程序员 从微服务走向单体化
14 天前
回复了 anivie 创建的主题 程序员 Win+ Linux 开发环境结合
这里说的 IDE 应该是 jetbrain 他们家的. 之前搞 presto 的时候, 在 Linux 下方便些, 就在 hyperv vm 里头起了 https://hub.docker.com/r/kasmweb/desktop 通过 webUI 来使用 Linux 里的 IDE
14 天前
回复了 lx271896700133 创建的主题 程序员 普通程序员还有活路吗?
建议还是把这类话题的给挪到 每个月都会出现的那种主题: https://www.v2ex.com/go/monthly
14 天前
回复了 lx271896700133 创建的主题 程序员 普通程序员还有活路吗?
隔一段时间就会提出这些问题, 我都怀疑这是不是为了故意给自己制造热度
https://v2ex.com/t/1089194
https://www.v2ex.com/t/1023860
https://v2ex.com/t/1078535
https://www.v2ex.com/t/1049518
24 天前
回复了 iintothewind 创建的主题 程序员 golang, 开发效率低执行效率高的语言?
我更偏爱 if err != nil, 控制流看着更清晰些. java 里的 `Integer.parseInt` 如果失败, 就直接抛异常. go 里的对应方法, 返回 (int, error), 能提醒调用者处理异常(给个默认值, 或者向上抛). 但没搞出类似 rust 的 `?` 的语法糖来避免 if err != nil 满天飞这点没得洗

感觉说 java 啰嗦大多是因为, 业务逻辑一行都没写, 先定义一堆 interface (哪怕只有一个 class 实现), 在定义一堆 setter, getter, toString, eqTo (有了 Immutables 能好很多)

我还是比较反感 orm, 稍微复杂点的 sql 用 orm 实现就费劲, 而且生成的 sql 不可控, 没法做些优化. 以及 n+1 之类的问题 https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/

多提一句, 感觉 golang 不适合做 web, 更适合搞重网络 IO 的应用
41 天前
回复了 seedhk 创建的主题 程序员 关于数据库容灾缓存方案的咨询
@seedhk 可行. 但 ck 没有 join reorder, 写 join sql 的时候得是大表在左, 小表在右, 否则性能比较差. Doris 优化器做的还可以, 也可以考虑 Doris
41 天前
回复了 seedhk 创建的主题 程序员 关于数据库容灾缓存方案的咨询
复杂查询估计是 AP 类型的, 建议上 clickhouse/Doris

救急的话, 与其上 redis 不如考虑拆分实例, 核心服务读/写单独的实例, 通过 DTS 把数据同步到复杂 sql 读的实例, 这样开发的工作量小些
@shijingshijing 之前用过 vs 写要跑在 Linux 下的 cpp 项目, 感觉远程开发远不如 vscode.
48 天前
回复了 aababc 创建的主题 程序员 golang 中 error 如何影响 log 和 api 状态
"是要么写入日志要么返回错误,而不应该两件事情都干。" 可以同时干呀.
就这个例子来说, 可以把返回的 err 记录到 resp.body 里头, 加个中间件记录 access log. 按你这套方式记录日志太麻烦, 而且还不能把 log 跟请求串联起来
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1883 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 03:56 · PVG 11:56 · LAX 19:56 · JFK 22:56
Developed with CodeLauncher
♥ Do have faith in what you're doing.