V2EX › looplj 的所有回复 › 第 19 页 / 共 57 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 ... 15 16 17 18 19 20 21 22 23 24 ... 57

❮

❯

2022 年 1 月 25 日

回复了 loriann 创建的主题 › 职场话题 › 绩效垫底。。。问下广大 v 友，测试发出的程序有问题算开发还是测试的锅？

两个都有锅，我觉得 55 开吧

不过，领导这么说话的公司呆着干嘛

然后，要看几次线上事故的原因是不是类似，反复犯同样的错，自己也需要反思下。

2022 年 1 月 25 日

回复了 714105382 创建的主题 › Kotlin › Kotlin 的协程是真协程吗？被 b 站博主搞蒙了

go 的协程也会阻塞系统线程啊

只是 Go 的所有 IO 操作被封装过而已，不会直接调用系统 io

和 Kotlin 的效果是一样的，只是 kotlin 的想要不阻塞系统 thread ，需要调用特定 API 而已

2022 年 1 月 23 日

回复了 caicaiwoshishui 创建的主题 › 程序员 › 对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全

@0xsui #59 见过，想骂人，国外的 quickbooks ，API 查询直接写 SQL 。这可是国外流行的财务软件，母公司市值 1500 亿刀，

2022 年 1 月 23 日

回复了 WangLiCha 创建的主题 › 程序员 › 项目组零基础转做前端，类似一个在线的可交互 PPT，求助思路

搜索
open source ppt online

找到了几个库：revealjs ，Impress.js
等，好像还带了协作功能

半年不太可能实现，web 还需要后端配合，这个也不简单。

2022 年 1 月 23 日

回复了 caicaiwoshishui 创建的主题 › 程序员 › 对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全

@avastms #37 RESTful 最重要的是对业务建模，一个资源对应后端一个业务模型，所以其实是能在大部分场景使用的。只是业务模型和前端 UI 并不完全对应，所以前端的时候一般会都套上一层 BFF 。

2022 年 1 月 23 日

回复了 caicaiwoshishui 创建的主题 › 程序员 › 对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全

1. 公司或者部门有规范，按照公司规范来，没有的话，公司有点问题，没做好
2. 老项目，按已有的 API 规范来
3. 新项目，看项目能不能达成一致使用 RESTful 风格的 API 设计，不能达成一致，使用 RPC 风格的 API 也不是什么问题

当然，面对说 POST 更安全，这种极其不靠谱的后端，可能及时跑路更好

2022 年 1 月 22 日

回复了 caicaiwoshishui 创建的主题 › MacBook Pro › 2019 的 mbp，早上去天才吧检查电池，既然给免费更换，大赞

我 17 年的都免费换了

2022 年 1 月 22 日

回复了 SuperMild 创建的主题 › Go 编程语言 › 据说 Go 2.0 的错误处理有可能是这个样子

@SuperMild 有了泛型更好玩一点

https://i.imgur.com/cYddxY9.png

2022 年 1 月 22 日

回复了 LxnChan 创建的主题 › Node.js › 升级了一下 node，出大问题了

作为后端，负责一个 admin 项目，然后收到 dependabot 的提示升级 chore(deps): bump axios from 0.21.1 to 0.21.2 的 PR ，然后 merge 了，然后页面挂了。
一脸懵逼，这兼容性也太差了。

2022 年 1 月 22 日

回复了 SuperMild 创建的主题 › Go 编程语言 › 据说 Go 2.0 的错误处理有可能是这个样子

@Joker123456789 写分布式应用的情况下，每个步骤的错误都需要仔细处理的时候就会觉得 try catch 很麻烦。go 的这种错误处理在这种场景下用起来还不错，但是写业务的时候，大部分中间步骤不需要处理，直接抛出，当然 try catch 很爽。
Result + ? 操作符，这两种情况场景处理起来的感觉都不错。

Go 的 error 对应的是 Java 的 checked exception ，和 Rust 的 Result<T, Err> 本质是一样的，只是用起来方不方便而已； Go 的 panic 对应的是 Java 的 runtime exception

2022 年 1 月 22 日

回复了 SuperMild 创建的主题 › Go 编程语言 › 据说 Go 2.0 的错误处理有可能是这个样子

@SuperMild 可以兼容已有的库，只要最后一个返回值是 error ，就可以使用 ? 操作符。我知道社区早就讨论过这个方案了，也被拒绝了，在这里只是吐槽下，不能接受 Go Team 拒绝的理由而已。

2022 年 1 月 22 日

回复了 luckycat 创建的主题 › 程序员 › 订单成功状态应该用 succeed、success 还是 successful ?

首先，订单成功这个描述就有点模糊。
成功提交，成功发货，还是成功配送。
建议参考 #17 ，重新定义状态

2022 年 1 月 22 日

回复了 SuperMild 创建的主题 › Go 编程语言 › 据说 Go 2.0 的错误处理有可能是这个样子

和泛型一起提出来的方案。。
像 Rust 那样 ? 不好吗
为了不承认自己设计错误，搞的大家的代码看起来那么恶心，写起来也恶心。
真是无语了

2022 年 1 月 15 日

回复了 firhome 创建的主题 › 程序员 › 请教后端同学这种写接口的方式对不对？

RESTful API 就是这样的，很多逻辑在前端。后端只负责业务建模，不负责前端 UI 逻辑，因为业务逻辑不会经常改变，但是 UI 逻辑经常改变。
所以现在有 BFF 的架构，一般使用 GraphQL 做 BFF 中间层。