什么样的代码算是好的代码， review 应该具有哪些品质

45 条回复

1

v2er119

2025 年 4 月 22 日

哪有什么好代码，代码为业务服务，极致的体验，最好的代码是机器语言。可读，可维护与极致性能大多场景下是冲突的。

2

MrRongts

OP

2025 年 4 月 22 日

写了好长时间的业务代码，功能都自己测试过了，review 后很多地方都要改，完了又要重新测试，想想都头大，你们是怎么解决的？

案例代码

```js
// 我的代码
// 把数组转成 key-value 对象
const arr = [
{ id: 1, name: 'a' },
{ id: 2, name: 'b' },
{ id: 3, name: 'c' },
];

const obj = arr.reduce((acc, item) => {
acc[item.id] = item.name;
return acc;
}, {});

console.log(obj); // { '1': 'a', '2': 'b', '3': 'c' }

// review 人员：
// 团队都这样么，你那么写，别人不好看的懂，reduce 通常用在 xxxx ，没听进去
// 改成这样
const obj = {}
for (let i = 0; i < arr.length; i++) {
const item = arr[i];
obj[item.id] = item.name;
}

```

3

nealHuang

2025 年 4 月 22 日

2

@rts1005410788 review 是极具个人色彩的行为，结果的好坏完全取决于 review 者的编码水平。就跟别人点评某个作者的文章好与坏一样。但代码与文章不一样，如果你们公司要求保持统一的代码风格，那你可以通过测试用例来体现你的编码能力，确保期望输入和输出与需求保持一致，中间的代码就按照规范来就好，不用太纠结，打份工而已

4

y547679519

2025 年 4 月 22 日

如果有规则按照规则来就行了，面向工资编程，怎么写代码能涨工资就怎么写。

5

lonjin

2025 年 4 月 22 日

review 者水平差的话简直就是灾难

6

yanqing07

2025 年 4 月 22 日

@rts1005410788 #2 如果有重复测试的话，你应试写单元测试来保证代码功能。手工测效率太低，而且后面有修改，单元测试不通过也能发现问题。当然，会出现单元测试修改来迁就业务代码。这时，应该将稳定的代码抽出来做一个 function ，这样业务部分修改也不影响，这个 function 单元测试也能少修改

7

lcbp

2025 年 4 月 22 日

功能正常，边界处理，高内聚，低耦合，高完成度，目录清晰，命名通俗易懂，有文档。

8

clemente

2025 年 4 月 22 日

都 AI 时代了... 不是核心代码
其实只要变量写明白点就好...

9

clemente

2025 年 4 月 22 日

我理解是不要过度设计越简单越好
到头来很多架构是最简单的最优雅最可靠

10

youyouzi

2025 年 4 月 22 日

1

@rts1005410788 你们 review 通常不是你们 leader ？这水平还不如你，怎么敢 review 你的代码还大放厥词的。

11

youyouzi

2025 年 4 月 22 日

@rts1005410788 就算要循环，也是这样比较简单吧：

const obj = {};
arr.forEach(item => {
obj[item.id] = item.name;
});

12

jackOff

2025 年 4 月 22 日

可维护性好，可读性强，尽量大白话，少用抽象和注解，高度泛型抽象的拉过去打一顿问问你这破业务值不值这么玩，不过度依赖框架，命名规范，尽量不要命名方法和类高度相似的，禁止使用魔法值，统一管理全局静态类，全局变量尽可能放到一个类里，全局变量和静态类，枚举类必须有注释，禁止在正式项目里塞数据库代码生成器这些奇技淫巧，有足够接口文档，并且接口文档要有接口范例，前后端统一 post 请求，项目启动和部署尽可能提供一键脚本，最好有文档，哪怕主程序和组长突发意外死亡也能立刻找人接手

13

shench

2025 年 4 月 22 日

据我多年的工作经验来说，能满足老板要求能运行的就是好代码，其它都是扯淡

14

MrRongts

OP

2025 年 4 月 22 日

@youyouzi 他就是 forEach ，我纠结的 review 时候，真的有必要纠结这种细节代码，搞的被 review 那个人很没有自信。比如我，😂

15

jackOff

2025 年 4 月 22 日

补充一下，任何与跑项目没关系的代码生成工具都禁止放到项目里，这东西设计的人过于个性化，鬼知道今天把你裁了后面接手的能不能看明白你写的鬼画符

16

somebody1

2025 年 4 月 22 日

好的代码就是，1000 行的代码，看个三五十行就能理解做了什么事情，改起来不会瞻前顾后，能很快定位到要改动的地方。

17

youyouzi

2025 年 4 月 22 日

4

@rts1005410788 #14 不必在意。你的写法已经很优雅了。

我是 review 的人的话，看到你这个代码是没问题的。

反而组内很多人喜欢写循环操作，我会让他尝试换个思路，提升一下技能。

当然，不是强制要求，毕竟每个人对工作态度不一样，不是太混的，写的太恶心的我一般都是直接 merge 了

18

godmiracle

2025 年 4 月 22 日

能实现功能能赚钱的就是好代码

19

soulflysimple123

2025 年 4 月 22 日

不同的写法，只要可读性，性能没问题就行，纠结这些真没啥意义。

20

Nyeshuai

2025 年 4 月 22 日

@rts1005410788 #2 这就是适合用 reduce 的场景, 这 review 的已经暴露水平了. js 写业务真用不上传统 for, 要用也是 for...of 啊, for 一出至少三行, 早些年还有些性能优势, 现在也就需要中断才用了.

21

h1104350235

2025 年 4 月 22 日

review 的人代码质量还不如你

22

jjwjiang

2025 年 4 月 22 日

你能就着他的 comments 争论赢他吗？比如他给的理由我觉得还是很充分的，你真的想推进，可以回复说 reduce 更优雅且更不容易出现越界问题，如果团队大家不了解我们是不是可以考虑做一下技术分享让大家更了解 ES 的新 feature 和 api ，提提高整体代码质量？

如果你没这个本事在他给出合理理由的情况下，用更合理的方式驳倒，那就只能照着做了

个人不觉得这是什么很苦恼的事

23

Pythoner666666

2025 年 4 月 22 日

1

兄弟单说对 js 这门语言的掌握，你的水平高他一个层次。

24

heftyMan

2025 年 4 月 22 日

reduce 都看不懂还干什么开发，你们同事 base 低于 1w ？

25

zzzyyysss

2025 年 4 月 22 日

1

这个用 reduce 应该没问题，但应该尽量避免用 reduce 很容易让代码变的晦涩难懂。

26

ychost

2025 年 4 月 22 日

第一眼代码一定要是整洁的，然后内部逻辑要干净，比如 while + flag 这种判断肯定就设计的不好，还有就是代码注释、命名合理、NPE 处理等等，好代码、差代码还是能体会到的

27

wangsahala

2025 年 4 月 22 日

你的代码没问题，reduce 比单纯循环简洁，清晰一些

28

listenerri

2025 年 4 月 22 日

1

OP 示例的代码在 MDN 上不建议使用 reduce ，而是推荐使用 for 循环代替：

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce#when_to_not_use_reduce

29

listenerri

2025 年 4 月 22 日

另外，新手能看懂的代码是好代码

30

AnotherSola

2025 年 4 月 22 日

不好说，以前我也觉得选择合理的 API （即使是冷门 API ）、精简代码、用各种骚操作（&1 判断奇偶，~~取整等）是更好的，也觉得这就是自己的技术，会纠结各种代码细节。但我现在不这么想了。不管是做技术还是做业务，最后看的都是你做出来的东西是否好用是否能创造价值，和你代码用 reduce 还是 forEach 没有半毛钱关系，所以没有必要纠结。说要改就改，因为你还没有话语权，觉得同事太菜那就提升自己跳去更大的平台，祝好