Skip to content

周刊第4期:独立思考

Published:

本周做了啥

给日常使用的 vscode-hg 扩展提了两个没什么技术含量的 PR,顺便蹭了一个 contributor:

分享文章

一些本周阅读过的好文章、以及我的一些总结和个人思考;非常建议你直接阅读原文,毕竟一千个读者就有一千个哈姆雷特,而且我的理解可能是错的。

useMemo 和 useCallback 之间的深入比较

原文地址:《A Deep Dive Comparison Between useMemo And useCallback》 | Technical Blog

以下是它们的实现方式:

function updateCallback<T>(callback: T, deps: Array<mixed> | void | null): T {
  const hook = updateWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;
  if (prevState !== null) {
    if (nextDeps !== null) {
      const prevDeps: Array<mixed> | null = prevState[1];
      if (areHookInputsEqual(nextDeps, prevDeps)) {
        return prevState[0];
      }
    }
  }
  hook.memoizedState = [callback, nextDeps];
  return callback;
}
function updateCallback<T>(callback: T, deps: Array<mixed> | void | null): T {
  const hook = updateWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;
  if (prevState !== null) {
    if (nextDeps !== null) {
      const prevDeps: Array<mixed> | null = prevState[1];
      if (areHookInputsEqual(nextDeps, prevDeps)) {
        return prevState[0];
      }
    }
  }
  hook.memoizedState = [callback, nextDeps];
  return callback;
}

初级开发人员如何为新团队提供价值

原文地址:《How You As a Junior Developer Can Immediately Provide Value When Joining a Team》 | Technical Blog

个人思考

作为一名初级开发人员可能认为自己只能负责最简单的一部分业务,并没有意识到自己能给团队带来这么多价值,但其实你可以通过你作为一个新成员的位置,去发现你刚加入的团队一些不好的习惯,通过正确的心态和行动去改变现状。

你的代码不必完美无缺

原文地址:《Your Code Doesn’t Have to Be Perfect》 | Technical Blog

作者通过一段经历,讲述他在实现某个功能时,由于想要实现最佳的解决方案,一开始就花费了大量的时间去进行完美的设计、抽象和封装,结果一个星期的时间没有任何真正的业务产出。

以下是作者一些教训:

个人思考

每个开发者都经历过这个阶段,想要一开始就设计好所有的细节、编写最完美的代码,但这是不可能的,所有代码都是经过不断地重构。你的代码不必在一开始就完美无缺,在生产项目中更是如此,毕竟不存在没有 deadline 的项目,只要懂得这个道理,你的工作效率会大大提高。

关于编写可读代码的最重要的事情

原文地址:《The Most Important Thing I Learned About Writing Readable Code》

编写代码时最重要的是可读性,一段难以理解的代码,即使你已经知道它的目的,你也很难理解它。所以编写具有可读性的代码是非常必要的。

已经有非常多的经典书籍在探讨这个话题,例如:

本文作者之前也写过几篇关于代码可读性的文章,不过我认为大部分已经是老生常谈了:

但作者认为有一件更重要的事情被忽略了,那就是:沟通。

每个人对于「代码是否具有可读性」的理解都不一样,所以日常中经常会出现下面这种对话:

这种回答并非完全没有道理的,但它们都有共同点:他们之所以不同意使用这种实现会使代码可读性更差,是因为他们觉得自己能够理解这样的代码。

的确,他们确实非常熟悉这段代码是如何工作的,但他们搞错了一件事:他们认为我是因为理解不了这段代码,才觉得这段代码难以阅读。

然而事实并非如此,因为问题的根本在于:代码的可读性与你无关,而是与其他人有关,准确地说,是与未来接手这段代码的人有关,甚至这个人很可能就是六个月后的自己。

所以,你要为他们编写具有可读性的代码。

个人思考

首先我需要说明,我并不认同作者提到的「 for-loop 可读性比 Array.reduce 好」这个结论,我认为 Array.reduceforEachmap 这些标准方法并无不同,不是 JavaScript 的糟粕,甚至是精华部分;另外 Array.reduce 真正需要考虑的细节也不多,只要熟悉递归思想,它其实很好理解。

除此之外的大部分观点我都是非常认同的,特别是本文讲到的「沟通」二字。我曾待过一个团队,当时合并代码前是需要两人交叉 Review 的,也遇到过几次关于「这样实现的可读性好不好」的问题展开讨论,基本都是各执一词,往往这种时候都需要一个第三者来进行判断,由这个人决定采用哪一种实现。

还记得有一次更离谱,某位同学酷爱使用位运算符,他对此给出的理由是:这样实现会使代码更快。

首先我并不认同这种说法,因为他没有给出专业的对比分析,即便这是真的,但在我们负责的这种 Web 项目中,这种速度的提升简直是可以忽略不计的,所以我就「可读性」本身这件事与他讨论,结果他开始和我解释这个位运算符是如何工作的,这位同学就犯了上面提到的问题,其实我不是不理解位运算符如何工作,我还曾写过一篇《深入理解按位操作符》的文章,我只是单纯认为不应该在项目中使用位运算符罢了。

有趣的链接


作者 : 4Ark

地址 : https://4ark.me/post/weekly-04.html/

来源 : https://4ark.me

著作权归作者所有,转载请联系作者获得授权。