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

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

写了好长时间的业务代码，功能都自己测试过了，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;
}

```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

review 的人 代码质量还不如你

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

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

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

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

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

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

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

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

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

@listenerri #28 ，好隐晦的说了 reviewer 是 **对于缺乏经验的 Javascript 开发人员**

"我写的就是，别人写的就不是"

可能是我太菜了, 我喜欢 forEach 一个个给 kv 对的写法.
reduce 虽然也能一眼看懂,但总是在脑子里转一下.类比就像看一些文字,reduce 就是英语而 forEach 就像看汉语母语

能让初级开发一眼看懂，又能让高级开发大呼牛逼的代码

那我用 `Object.fromEntries(arr.map((item) => [item.id, item.name]))` 该如何应对呢
实际上常规的 review 对于这种问题就不该指出，能实现需求怎么写都一样。

@listenerri 哈哈，你这个说服力就很强了

有规范按规范吧，没规范就很抽象了，以前和同事互相 review 过，只要易读还是会保留个人习惯性代码的。

写复杂不难，最难的是怎么写简单

大道至简

@dfkjgklfdjg 团队协作，能让实习生都能轻易看懂且马上上手的就是好代码，减少沟通成本

@Cannian #40 ，好理解好上手，不代表成员可以菜

能被 AI 理解的

牛马不要为难牛马

review 你的人看不同 reduce 是它的问题

review 的话，看在什么地方，有的地方 review 会给你做成完完全全的批斗大会，难以直视