团队协作中，当需要做一件事情可能会问，“嘿，我打算做 X，你同意吗？”，去征询对方的许可。

但是许可意味着对方需要承担一定的责任，当这件事情没做好，可能会被甩锅，“我问过 Y 的，他说可以的。”

所以许可可能会给对方带来责任和压力，让对方不愿意合作。

如果换一种说法，“嘿，我打算做 X，你有什么建议吗？”。

去寻求建议而不是许可，给建议是不需要对方承担责任的，这样对方会更放心地提供意见，从而得到一些中肯的建议。

提供建议相比许可，也让对方多了一些参与感，会让对方对事情的结果增加兴趣。

相比上来就问算法题，八股文，作者更推荐一种面试题：

这是您以前从未见过的存储库。以下是如何在此存储库中构建和运行测试。

有一个错误：我们看到结果是 X，但我们想看到 Y。

找到错误原因，或者可能编写一些代码来修复它。

作者认为这类题目的好处有：

• 反映了日常开发的流程。

• 比较有趣。

• 问题明确，面试者不用去揣测面试官到底想问什么。

• 能看到候选人实际开发的一些环境，方法。可能会看到对方能非常熟练地使用 vim，linux，或者调试方法很高效等。

其实就是把一个日常开发问题给面试者，看他如何解决，从而可以在多种方面观察面试者是否符合要求。

NodeJS 计划将 Corepack 删除，不内置在 NodeJS 中。

Corepack 是一个 NodeJS 脚本，允许你使用 npm，yarn，pnpm，而无需安装它们。

促成这个计划，是因为有人建议把 Corepack 开启。

BYTES 作者的评论是：

Let that be a lesson to anyone else who dares to publicly question the authority of npm.

让这成为任何敢于公开质疑 npm 权威的人的一个教训。

有种 “你们敢质疑 npm？那我就把 corepack 删了。” 的喜感。

不好的重构：

• 改变了代码风格，添加不必要的依赖，导致代码的不一致性

• 不必要的抽象，原来一个函数就能解决，没必要抽象一个 class 实现

• 不理解原来的代码逻辑，导致功能丢失

• 不了解业务背景，实现的逻辑没有业务价值

• 过度整合代码(@see: Goodbye, Clean Code)

前阵子做也在重构一段代码逻辑，以为已经完全掌握这段逻辑了，结果测试的时候发现执行出错了。

原来的代码中存在一个 forEach，用于从数组中查找一个符合条件的元素。

我重构的时候就换成了语义更合适的 find，但 find 是只找第一个符合条件的元素。

而原来的逻辑中，数组中存在多个同名的元素，用 forEach 实际会找到最后一个匹配的元素，用 find 是找不到的，这就导致了逻辑执行失败。

有用例去兜底很重要，不然改完都不知道改错了。