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

V2EX = way to explore

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

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

国外的同事来国内出差，趁着这个机会，邀请他跟我们一起进行 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 条附言 · 2 天前

团队中有好几位热门开源项目的 contributor ，他们写业务代码也跟写中间件源码一样，导致代码中存在严重的过度设计，60% 以上的预留扩展点，估计等公司没了都用不上。

他们代码写爽了，接手的人一看惨了，调个 "1+1" 的方法要经历一堆 "接口、抽象类、实现类、回调、各种设计模式......" 才能拿到 "2" 这个结果。

这 2 种写法没有谁对谁错，一方水土养一方人，很明显国外的同事水土不服，不知道国内领导喜欢听一些装逼的名词，比如："高内聚、低耦合、扩展性......"

作为程序员，我内心赞成国外同事说的用第一种写法。1 行代码就搞定，简单明了，等到需要扩展的时候再去抽取不就行了。

但作为 "国内的程序员"，我也只能跟着用第二种写法了。没办法，国内领导喜欢第二种，如果你用 1 行代码就实现了，那领导会认为你工作过于简单，工作量极不饱和；而用第二种写法，各种设计模式绕来绕去的，没十天半个月根本看不懂，既能体现你技术上的不可替代性，又能提供足量的代码......

第 2 条附言 · 2 天前

大家轻点喷，因为 review 的是 Java 项目，所以我写了 Java 伪代码来演示这种情况，直接用 Go 也没办法写出这样的代码，我本人也是 Java 转的 Go 。

关于具体业务，其实很简单，也不太可能有后续的扩展，都是留给以后用的。目前整个项目的代码风格都是这样的，可以参考 Apache Dubbo 源码（微内核+插件化+SPI 扩展），因为团队里好几个大佬都是其前 committer 。

code review

国内同事

国外同事

136 条回复 • 2025-11-08 17:50:46 +08:00

1 2

❮

❯

101

JoJoWuBeHumble

2 天前

我一般都是先写一行。
后期如果出现任务内容过度和要在多个地方这样开线程，才会单独提出来成为一个 Task 类

102

digdug

2 天前

俺一看是 java 俺就懂了

103

dif

2 天前

@kkwa56188 你就说有没有放屁的时候，有可能带点私货出来吧。如果是很熟悉业务，过度设计也没啥，毕竟大概知道以后这一块会变，因为开会的时候或许讨论过，但因为各种争论悬而未决，但业务还要推进只能把这一块做个预留过度设计一下。

如果没有任何争议的开发，起手就过度设计。本来一个简单的功能，半天一天就能完成，非要做各种兼容，什么设计模式之类的搞得很复杂。这种不提倡，因为大概率这一块就算有修改，也不是靠设计模式就能解决的。还不如遇到问题，再做重构和修改。

104

imesrdfi8dzs

2 天前

我支持老外的代码。
因为我最近在做二开，没有源码，看 class 代码，各种设计模式和优化后的东西。
我看了三天，在 20 几个类里，在它们的组合关系、多实现的接口、各种组合缓存、一堆 Consumer 集合里来回跳跃看得头都晕了。
不可否认，代码是优化得挺好的。但是预留出来的让二开用于拓展的口子用不到、或者说不够用不好用。但是对开发效率的阻碍确实实打实的。

105

IndexOutOfBounds

2 天前

方案 1 当下最简单，简单就是好

如果考虑扩展性，先考虑演进吧，不是上来就优化

后续可以丝滑演进到方案 2 ，这不也是”扩展性“？

除非很难演进，避免以后真有需求难改，才考虑直接上方案 2

106

7beloved

2 天前

抽象

107

HangoX

2 天前

思考点很简单，如果这个地方以后要扩展，改起来是否很麻烦？只是很小的改动，那么就只要直接写简单的，后续再改。特别是那种业务类型的，你永远猜不到扩展。写太多的模板代码，只是让后面的人不好改而已

108

systemGuest

2 天前

国情不同，老外不必大惊小怪。
Java 在国内就是面向对象，new 来 new 去才能体现出专业，这种繁琐臃肿的风格深受 gov 喜欢。
有时候不是把事情做简单做高效了就是最好的，在中国，把事情做“高大上”了才是专业，合规。

109

cocong

2 天前

等不到扩展公司先倒闭了

110

66beta

2 天前

我 TM 太懂你了，刚刚接手公司另一个组的项目，我愿称其为<过度设计仙人>
如果没记错的话，之前开发的那位老哥是京东出来的

111

yanguangs

2 天前

@WngShhng
medium 的文章 = 垃圾

112

reatang

2 天前

1 、打工人都清楚，在资源有限的情况下，写出来的代码是永远不会变动的。即便是一坨 shi 。
2 、能根据需求把模块拆清楚已经是大部分同学的极限了，产品一句话你的设计立马崩溃。
3 、如果要写设计模式，你就得比产品更懂产品，上升到领域专家。否则面条代码就非常好。

113

workshop

2 天前

做到让人无法替代

114

fatpower

2 天前

你的例子举的没有意义，还是要结合实际业务来，这段代码所做的业务，有没有后续扩展的可能

115

dongisking

2 天前

一般来讲，只有 TL 或者组长适合写 2 这样的代码，其实大部分普通程序员肯定是想写 1 的，很多时候遇到需要抽象的时候，普通程序员是意识到需要写 2 来满足高内聚低耦合和设计模式，但是这时候你写了一个 2 ，别人写的代码你敢改吗？改了相当于变成你成了最后的修改人，内心多一事不如少一事。

总的来说，这两者现在大部分程序员都意识到优缺点，区别在于决策者，普通程序员不希望揽责，TL 应该写第一种

116

burymme11

2 天前

在国内写代码用设计模式 99%都是屎上雕花。

117

oppoic

2 天前

以前的我：各种框架源码真是厉害，看了半天我都没找到这个变量咋赋值的。我真菜啊
现在的我：不管是类还是接口，超过 3 次的继承或封装，都不是好代码。嘿嘿嘿嘿

118

shylockhg

2 天前

我比较喜欢的是 Log Structed Merge 形式，总之就是不要提前设计，而先实现功能，然后实践总结，最后再重构

119

shylockhg

2 天前

@shylockhg Log Structured Merge

120

xiaomushen

2 天前

这设计模式，可以拉出去枪毙就好了，全世界都清净

121

xmdbb

2 天前

这种我觉得要结合场景才有意义。

比如所谓的“过渡”化设计，只是因为“公司没了都用不上”，但谁又能预知到公司的命运，又能预支公司的业务变化呢。

最简单的一个事情，你是愿意用 100 元购买一个功能丰富，但大部分功能可能是用不上的工具。还是愿意花同样的价格，购买一个只能满足你当下功能的工具？
如果功能丰富的工具要 3 天才能送到，而简单的工具当天就能送达，你会怎么选择？
如果你是当天就要用和七天后要用，你又会有怎么不同的选择？

所以最终决定选择哪一种，需要根据实际场景来进行。