V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ljzxloaf  ›  全部回复第 3 页 / 共 12 页
回复总数  234
1  2  3  4  5  6  7  8  9  10 ... 12  
理想很丰满,但是能做到何种程度就难说了,就像项目立项时都奔着改变世界去的,最终大多数结局是“能用就行”。
http status code 是与业务无关的,业务相关的 status 还是需要通过报文返回,所以我们讨论的其实是业务无关给状态应该如何返回。其实用啥都可以,但是如果用 http status code 的话会增加一些沟通成本和程序员的心智负担,因为要学习和沟通两套 code 。我觉得能 All in one 都尽量 all in one ,看看现在企业的各种平台不都是能集成在一起的都集成在一起了,多转个圈就多了一分成本。

而且现在有些公司用 http 是对外的 web 接口,有些公司则直接用 http 作为 rpc ,后者如果为了以后升级方便,应该尽量不要依赖 http status code ,http 仅作为传输层使用。
2022-12-01 01:30:09 +08:00
回复了 ljzxloaf 创建的主题 程序员 怎么恢复 APP 和 WEB 端的颜色
@xifangczy #4 谢谢,亲测可用
2022-12-01 01:18:07 +08:00
回复了 ljzxloaf 创建的主题 程序员 怎么恢复 APP 和 WEB 端的颜色
@dot #2 离不开 b 站小姐姐😂
2021-09-02 18:10:38 +08:00
回复了 v2byy 创建的主题 程序员 task 切分和汇总 在 cloud 环境中如何设计?
用 mq 挺好的,自带进度管理,client 宕机恢复,自动 rebalance 。就是要把任务多倒腾几趟,多些资源开销。
2021-08-24 05:46:41 +08:00
回复了 pocarisweat 创建的主题 程序员 看到「学什么新语言」这个问题,推荐这本书
有用 C 写 crud 的吗
2021-08-24 05:22:24 +08:00
回复了 byzf 创建的主题 程序员 闲来无事,求推荐点三个月左右能入门的兴趣爱好、技术方向
写小说 /homelab/厨艺 /vlog/播客 /blog/github
2021-08-23 10:46:07 +08:00
回复了 golangLover 创建的主题 Java Spring 应对 IO 密集 的 web 业务系统有什么成熟的做法
2021-08-16 23:26:37 +08:00
回复了 1sm23 创建的主题 信息安全 中了 crpytowall 勒索病毒
@ljzxloaf #26 好吧,是节点的原因。。
2021-08-16 23:25:13 +08:00
回复了 1sm23 创建的主题 信息安全 中了 crpytowall 勒索病毒
2021-08-16 23:04:11 +08:00
回复了 beryl 创建的主题 程序员 代码优雅实现讨论
需要换个角度去思考问题。

打个比方,产品需求描述一般是用户场景和交互流程,而这些变化是非常快的,我们不可能给每个场景、每个流程写一套代码,所以需要从业务模型的角度去思考,而不能从业务流程的角度去思考。比如你这种就可以看做是几种业务模型组合起来的流程,其中的业务模型有第三方业务、缓存、日志等,我认为你这种写法没啥问题。如果有些逻辑重复读较高,可以根据业务更为细致的封装。比如 A 业务与 B 业务组合起来形成一个业务。这种组合就看具体需求了。

流程与对象是相对的,流程的每个节点都是对象,对象的内部逻辑也是流程。

实践中,我们一般可以同时提供两种接口:一种是不依赖其他业务的“原子”接口;另一种是依赖其他业务的“组合”接口。

比如搜索,我可以同时提供:返回 id 集合的接口和返回 item 集合的接口。item 信息是我从 item 服务拿到的,这样我等于组合了 item 服务和搜索。反过来也类似,比如敏感内容过滤,我也可以提供两种接口:传参 id 集合和传参 item 集合,如果只传 id 我需要去 item 服务查 item 信息,就是组合接口;如果传给我 item 集合,我就不需要去依赖 item 服务。

这种做法有什么好处呢?我们可以先考虑这样一个问题,我们有底层服务 A ( atom ),有两个上层服务 C1 、C2 ( combination ),现在有个需求要调用 C1 的接口 C1.I1 和 C2 的接口 C2.I1 ,这两个接口都要调用 A 的接口 A1.I1 ,这样我们为何不先调 A1.I1 ,然后把返回的信息传给 C1 和 C2 呢?当然当我们没有这种冗余调用的时候,还是用原来的接口,这样更方便。

我分析下来这样做从性能方面应该是有利无害的。从 IO 方面来看,虽然直接传递 item 信息增加了传递参数的网络开销,但是由于不需要去查 item 服务,减少了一次 item 服务返回 item 信息的网络开销,这两者已经抵消了。而后者还减少了查 item 的请求网络开销,item 服务的计算开销,和依赖服务或 db 的计算和网络开销。所以性能无疑是提高了很多。

上面只讨论了最简单的情况,其实实践中远比这复杂。上层服务会依赖多个下层服务,组合是千变万化的,不可能为每种组合都开个接口。比如 C 依赖 A1 和 A2,那就要四个接口,依赖 A1 的接口( A2 信息通过传参);依赖 A2 的接口( A1 信息通过传参);都不依赖(全部信息通过传参);都依赖。假设依赖 n 个服务,就需要(排列组合 n 选 n 、n-1...1,0 加和)个接口(感觉像科里化过程...),所以还是要根据实际情况具体问题具体分析,只提供那些用户普遍需要的组合。
2021-08-14 22:37:25 +08:00
回复了 ljzxloaf 创建的主题 问与答 怎么在 x86 机器上调试 arm 架构的安卓 app
@marczhao #9 谷歌咋了
2021-08-14 21:59:12 +08:00
回复了 ljzxloaf 创建的主题 问与答 怎么在 x86 机器上调试 arm 架构的安卓 app
@marczhao #6 对的,我直接用的 11 的 image,按官方的说法是兼容 arm 的,但是我用下来大部分都不行。我是想看看一些 app 的设备指纹是怎么取的
2021-08-11 15:24:54 +08:00
回复了 waiaan 创建的主题 程序员 要多健壮的代码才能支撑起千变万化的需求?
ddd,如果業務模型發生顛覆性變化的話不能算是程序設計的問題。另外,這不叫健壯,這叫可擴展性。有個原則叫做 ETL ( easy to change )
2021-08-11 15:20:26 +08:00
回复了 ljzxloaf 创建的主题 问与答 Itellij idea 有这种功能吗
@sytnishizuiai #4 這個命令叫啥,我用的 Ubuntu
2021-08-09 18:31:24 +08:00
回复了 zshineee 创建的主题 生活 迫于减脂,中午带饭靠谱吗
每天少吃一点,渐渐的胃口就小了,别老想着一蹴而就。该吃啥还吃啥,但是要“浅尝辄止”,其实食物第一口是最美味的不是吗,尝到了前面的美味,没必要一直重复个没完。“光盘行动”已经不适合时代了,是要把国民吃成美国那种体型吗?我简直要怀疑这是医疗行业的阴谋了。
2021-08-09 00:08:43 +08:00
回复了 ljzxloaf 创建的主题 问与答 这种效果是 markdown 语法吗
结贴了,感谢
@yitingbai #4
@IgniteWhite #5
1  2  3  4  5  6  7  8  9  10 ... 12  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2474 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 02:17 · PVG 10:17 · LAX 18:17 · JFK 21:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.