V2EX tangkikodo 的所有回复第 1 页 / 共 3 页

怎么写（单元）测试？

要从可测的思考方式来书写代码，才有“可能”写测试

在写实现之前，或者实现之后里面套上测试，否则久了就不会写了

要懂得常用的 mock 第三方接口的方法，会构造数据整合查询一起测试

知道哪些应该写，哪些没必要

知道怎么结合 use case 来写

知道怎么结合 hook 在 commit 之前强制测试跑通

知道怎么划分出合适的 service 层并覆盖测试，避免在应用层写无聊的测试

想到更多了在补充。

关于只在 service 覆盖测试，应用利用继承和组合避免测试，可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md

2024-07-08 19:58:23 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@fescover
是的生态的优势非常重要

2024-07-08 14:22:45 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@justdoit123

gql 的另一个问题是数据结构关联按照什么模式来组织

如果按照业务模型的方式组织，那么面向具体的展示层，很多查到的关联结构要在 UI 上重新做调整。

如果按照 UI 的需求来组织，那么这个 gql 写起来就很没劲了。。变成了大号 rest

2024-07-08 14:16:55 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@ilvsxk

bff 如果不是前端去维护的话，感觉这个 bff 的组织划分就有问题哎。。（比如现在 node 就是 bff 的绝对优势语言（虽然我不太喜欢

本质上就是让前端自己组合出所需的数据，避免不必要的组合逻辑侵入到前端展示层。

2024-07-08 14:13:50 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@justdoit123 完全同意

我觉得这个工具其实不是给前后端对接用的，围绕着他的 DSL ，明明语言原生就有的类型，还得顺着它定义一套类型。嗦了。

臃肿的请求，前端自己通过查询串联起来许多服务，导致后端要调整的时候非常被动。

本来能用一个 client.load_xxx_data 搞定的事情，还得在前端维护一大串查询，这是对迭代很不友好的~

2024-07-08 13:49:03 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@ilvsxk bff 应该一头受气才对呀~~

2024-07-08 12:43:06 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@justdoit123
前后端都是 ts 技术栈，就非常丝滑。

但缺点就是你不能指望啥都用 node 来写吧 ~~

另外光 trpc 也不能解决如何高效且可维护地组合数据这个问题，如果能在 typescript 里面用

```
class Team {

member: Member[]
async resolve_member(loader=MemberLoader) {
return await loader.load(this.team_id)
}
}
```

这样地方法来组合数据，也会优雅很多的

2024-07-08 12:39:16 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@yrj

调整心态吧，有句话说“业务逻辑是最不讲逻辑的”

在没有深度分析的情况下，写 hard code 反而不失为一种最佳做法。

如果业务是个比萨斜塔，代码可能就是“高质量”的定制化支架。

2024-07-08 12:36:52 +08:00

回复了 BeiChuanAlex 创建的主题程序员 rss 现在还有人用吗？现在写一个 rss 的开源项目怎么样？

@lingo 已经 star 啦。

我用 rsshub 的数据做持久化之后，根据自己的 mark 历史，在尝试构建自己的信息茧房 ~~

2024-07-07 19:30:28 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@yrj 如果发现 service 层都会反复变更的话=。=

事情就难办咯

2024-07-07 19:29:08 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@SenseHu 架构整洁之道常看常新，之前对依赖关系的描述还比较迷茫，最近终于弄明白了。

这个模式也是受了 DDD 的很多影响，我也挺想总结为一套 clean architecture：）

2024-07-07 19:25:24 +08:00

回复了 tangkikodo 创建的主题程序员从前后端分工的利弊谈起，聊聊这套分工的未来方向

@yrj

我对业务逻辑反复变更的观点是，这是一个悲观主义者一定要考虑的情况。

这也是为什么我觉得面向 OPENAPI 的 RESTful 接口和 openapi-ts 之类的 client generator 的组合是所有方案中，对前端展示层跟随变动最友好的方式了。

不使用 client generator 的话，前端变更简直火葬场

使用 graphql 的话，前端跟着还要调整维护 query ，也是包袱。

但如果不维护这层，后端也不主动提供页面专供接口，那后果必然是前端拼拼凑凑，混入很多业务逻辑。

另外 BFF 这层防腐层，看情况是可以放在后端的，使用继承扩展 schema + resolver 的手段，后端也能够轻松的构建前端视图结构。（这就看组织架构上，根据开发资源决定哪边更适合做了）

比如我们的项目就是把这个组合层放在后端 router / controller 。

1 2 3