code review 把国外的同事气到吐血

查看 843|回复 83
cloudzhou   
抽象一般是你发现或者预见到了需要抽象的东西才去做,而不是自己去制造抽象
cloudzhou   
@winglight2016 哈哈,团队里好几个前 dubbo contributor ,很多业务代码也参照了 dubbo 的设计,使用 微内核+插件化+SPI 扩展,就是过度设计
ppooqq   
@midsolo 得看看你们在做时间什么事情,业务代码肯定不能过度设计,但是核心模块可以
leegradyllljjjj   
这里两个写法看不出什么,如果是我的话,会将这个 Task 的逻辑,写到具体的 Service
然后 TaskRunner 作为一个中间组件
到这个程度的话:
1. new Thread(() -> XXXService.DoSomething).start(); // 原生线程池,没有特殊处理
2. TaskRunner.Run("doSomething", () -> XXXService.DoSomething); // 中间件封装
为什么中间件封装:
1. 统计,监控,日志
2. 线程数量控制(即便是协程)
3. 以后 TaskRunner 控制复杂调度(优先级,丢弃,限流...)
如果你们是一个成熟的团队,本来就需要这些中间件,在这个基础上,都只是一个简单的方法调用而已
spike0100   
#32 上面的 1/2 区别很小,对于团队的人来说接受度没什么区别,所以你们的问题是:
复杂场景下,需要丰富中间件,而不是“按需开发中间件”,这样会增加其他团队成员的理解程度
superrichman   
说个常见的,IService/ServerImpl ,我写了多年代码也没遇上几回需要多实现的场景,我重来都是直接一个 Service
BingoXuan   
不好意思 我们是按代码量算钱的
sankemao   
@midsolo #13 确实如此。有时候你写的扩展,对接手的人来讲只是累赘。
newInterface   
啰里八唆的 JAVA 味道是这样的
cvooc   
最好加上 pool 去调度,任务开始前,创建上下文注入 thread local 去隔离变量就够了
您需要登录后才可以回帖 登录 | 立即注册

返回顶部