
国外的同事来国内出差,趁着这个机会,邀请他跟我们一起进行 code review......
公司的代码没办法拿出来,只能临时写个伪代码让大家鉴赏一下:
/** * 代码鉴赏:执行 1 个任务 */ public class JavaTasteSample { public static void main(String[] args) { // 国外同事:1 行代码就搞定,简洁明了 // ==(浪费了大量的时间在做过度设计,毫无意义的炫技)== new Thread(() -> System.out.println("task1 running...")).start(); // 国内同事:高内聚低耦合,把具体要执行的任务跟线程进行分离,方便扩展...... // ==(这老外太 low 了,连设计模式都不懂,估计不会写代码)== new Thread(new Task(new TaskInnerSupport())).start(); } } interface TaskInner { void execute(); } abstract class AbstractTaskInner implements TaskInner { @Override public void execute() { runTask(); } abstract void runTask(); } class TaskInnerSupport extends AbstractTaskInner { @Override public void runTask() { System.out.println("task2 running..."); } } class Task implements Runnable { private TaskInner inner; public Task(TaskInner taskInner) { inner = taskInner; } @Override public void run() { inner.execute(); } } 1 mb4555 5 小时 4 分钟前 单看着一行代码 支持老外 你这个封装有没有在其他地方用到 用到了 另说 |
4 erlking 5 小时 1 分钟前 支持老外 |
5 spike0100 5 小时 0 分钟前 我发现工作中至少 40%以上的预计扩展逻辑以后都不会用到。 |
6 lvtuyukuai 5 小时 0 分钟前 可以扩展的时候改写成第二种,每次新加功能重构已有代码方便扩展 |
7 visper 5 小时 0 分钟前 有时候,我更愿意去看一下写得很原始很差的复制多个地方的代码。而不是封装得十多差怎么也理不清关系的代码。虽然说为了扩展性。但是好像十年过去了也没有什么扩展。 |
8 LoNeZ 5 小时 0 分钟前 看场景..和重要程度... |
9 sneezry 4 小时 59 分钟前 按照我们公司之前的 review 风格,会支持国内同事的设计。现在一直在强调开发速度和营业额,没人在乎设计模式。 |
10 ohoh 4 小时 59 分钟前 为什么是国外的气到吐血了,国内的就不?这意思你已经明显站队了啊。 防御/预防式开发没啥问题啊,只是度有多大的问题。 |
11 xubeiyou 4 小时 57 分钟前 现在都讲究迭代速度和健壮性 不会在看设计模式了 除非真的有必要 |
12 askfilm 4 小时 55 分钟前 反正双标呗.... |
13 midsolo OP @spike0100 现在都是 流水式的员工 跟 快餐式的代码,绝大多数扩展逻辑都不会用到,如果换不同的人来接手,估计不会用上个人留下的扩展,会自己写一套 |
14 NO9527 4 小时 53 分钟前 我支持老外的,等这种设计模式狂魔的代码到你手里就老实了 |
16 stinkytofux 4 小时 52 分钟前 支持老外, 这种预留的拓展没必要, 需要的时候再把代码抽出来就是了. |
17 winglight2016 4 小时 50 分钟前 java 代码就习以为常,见怪不怪,看看 spring 的代码就明白了,恨不得你一行代码都不写,全部搞成无代码平台 |
18 MrPat 4 小时 50 分钟前 支持老外,度了,了而,等你需要用到留,可能你的代已要重了, |
19 96 4 小时 48 分钟前 Java 开发魅力时刻 |
20 chenluo0429 4 小时 48 分钟前 via Android 设计时预留实现扩展的可能性,不要堵死扩展的路就好。 千万不要真的实现扩展,除非你真的知道这里短时间内需要扩展以及扩展的明确方向。 |
22 darksword21 PRO 这种我统称为被 java 污染了脑子( |
23 qping 4 小时 45 分钟前 via iPhone 封了好几层每一层职责是什么?现在看起来什么事也没做,就是大肠包小肠 |
24 chenluo0429 4 小时 44 分钟前 via Android 绝大部分自以为是的扩展,最后根本用不上。其中大概一半多增加了不必要的复杂度,对相关开发造成困扰。一小部分会对后续的基于真实需求的扩展造成非常大的阻碍 |
25 WithoutSugarMiao 4 小时 44 分钟前 javaer 写代码考虑的真多。换成 python 的话,就没有这种烦恼,绝大部分 Pythonista 估计都会用第一种直来直去的写法。 |
26 songco 4 小时 44 分钟前 via Android 支持第一种 以前设计模式流行的时候,公司有的代码特别恐怖,所有的地方都支持扩展,但是 99%其实就一种实现 |
27 otakustay 4 小时 43 分钟前 现在有 Coding Agent 了,这种场景就算未来发现有扩展了改一套设计,找个 Agent ,明显有特征的代码( new Thread )全部扫一遍重构成新的方案,不要太简单 |
28 i8086 4 小时 40 分钟前 业务变化无法预知,不要过早优化,也不要过度设计。 这段伪代码,对应业务是什么?没对应业务,那肯定越简单越好。 |
29 zh6335901 4 小时 40 分钟前 抽象一般是你发现或者预见到了需要抽象的东西才去做,而不是自己去制造抽象 |
30 midsolo OP @winglight2016 哈哈,团队里好几个前 dubbo contributor ,很多业务代码也参照了 dubbo 的设计,使用 微内核+插件化+SPI 扩展,就是过度设计 |
32 cloudzhou 3 小时 48 分钟前 这里两个写法看不出什么,如果是我的话,会将这个 Task 的逻辑,写到具体的 Service 然后 TaskRunner 作为一个中间组件 到这个程度的话: 1. new Thread(() -> XXXService.DoSomething).start(); // 原生线程池,没有特殊处理 2. TaskRunner.Run("doSomething", () -> XXXService.DoSomething); // 中间件封装 为什么中间件封装: 1. 统计,监控,日志 2. 线程数量控制(即便是协程) 3. 以后 TaskRunner 控制复杂调度(优先级,丢弃,限流...) 如果你们是一个成熟的团队,本来就需要这些中间件,在这个基础上,都只是一个简单的方法调用而已 |
33 cloudzhou 3 小时 46 分钟前 #32 上面的 1/2 区别很小,对于团队的人来说接受度没什么区别,所以你们的问题是: 复杂场景下,需要丰富中间件,而不是“按需开发中间件”,这样会增加其他团队成员的理解程度 |
34 ppooqq 3 小时 12 分钟前 说个常见的,IService/ServerImpl ,我写了多年代码也没遇上几回需要多实现的场景,我重来都是直接一个 Service |
35 leegradyllljjjj 2 小时 52 分钟前 不好意思 我们是按代码量算钱的 |
37 superrichman 2 小时 33 分钟前 里八唆的 JAVA 味道是这样的 |
38 BingoXuan 2 小时 33 分钟前 最好加上 pool 去调度,任务开始前,创建上下文注入 thread local 去隔离变量就够了 |
39 sankemao 2 小时 32 分钟前 平白无故添加了认知负荷,人的精力是有限的 |
40 newInterface 2 小时 29 分钟前 我还见过在 java 里写 kotlin 的 |
41 cvooc 2 小时 17 分钟前 java 程序员特有的留着以后扩展用(然而并没有扩展) |
42 alienx717 2 小时 14 分钟前 claude code 给我写啥,就是啥,我不挑 |
43 Cooooooode 2 小时 6 分钟前 以前喜欢预留扩展,现在的工作基本是删除那些代码 |
44 aloxaf 2 小时 4 分钟前 想起一个 Java 笑话:一个程序员遇到了问题,他打算用 Java 解决,现在他有一个 ProblemFactory 了 |
45 xz410236056 2 小时 2 分钟前 看到 java 我就都明白了,干什么之前先来个接口 |
46 guanhui07 1 小时 59 分钟前 JAVA 味道是这样的 |
47 jsq2627 1 小时 55 分钟前 "Java 味" |
48 PaulSamuelson 1 小时 54 分钟前 为了以后可能用到,做的预留。Linus 看了直接开骂。 |
49 jsq2627 1 小时 53 分钟前 AI 时代,尽量把业务逻辑集中在一起,对 AI Agent 才是最友好的。可能要打破过去十几年形成的最佳代码实践了。 |
50 willchen 1 小时 53 分钟前 业务代码的话(通用的基础架构另说),就别过度设计了,产品分分钟打破你 |
51 midsolo OP @darksword21 确实有点,我从 Java 转 Go 的时候,大概好几个月思想才慢慢转变 |
56 akakidz 1 小时 20 分钟前 单从这里看,我觉得都没问题,还要看具体场景 |
57 liaohongxing 1 小时 5 分钟前 有用 lambda 的一律支持 ,支持第一种 |
58 wangguyu 20 分钟前 支持第一种,等要扩展的时候再复制一下代码改成第二种,没必要过度设计。 |
59 cubecube 13 分钟前 AI 都会 refactor 了,何必浪费时间绕来绕去。 |
60 simpleman 几秒前 问一下, 如果是内部的代码,有必要写成这样子吗? 业务拓展了内部重构不就行了? |