Skip to content

搞英语 → 看世界

翻译英文优质信息和名人推特

Menu
  • 首页
  • 作者列表
  • 独立博客
  • 专业媒体
  • 名人推特
  • 邮件列表
  • 关于本站
Menu

不要只写代码,也要阅读它!

Posted on 2023-02-21

不要只写代码,也要阅读它!

本文包含附属链接。有关更多信息,请参阅我的关联披露。

“阅读代码的次数多于编写代码的次数。”

这是编码人员中的一句著名格言,我认为,它已被普遍接受。这句话有时被归功于罗伯特·马丁,尽管他的书《清洁代码》中的直接引述更为具体:“事实上,阅读与写作所花费的时间之比远远超过 10 比 1。”

十比一!根据我的经验,这个估计是保守的。

所以这里有一个问题要问你:你花在阅读代码上的时间比写代码多一个数量级吗?

☉️
这篇文章最初发表在我的Curious About Code时事通讯中。不错过任何一个问题。在这里订阅→

无人谈论的技能

我随处可见:“代码应该是可读的,所以专注于编写可读代码!”

这听起来是个不错的建议,但却没有切中要害。重点是沟通周期的错误部分。如果你想学习如何编写可读代码,你最好花很多时间做一个读者,关注你的需求。

我了解到的关于“可读”代码的重要事实之一是:您不必迎合最低公分母。可读代码的目标不是让任何人都能轻松阅读。相反,目标是让目标受众理解。或者,在这种情况下,所有三个:

  1. 编译器。
  2. 作者。
  3. 未来的维护者。

安抚这三个人是具有挑战性的,我没有听到任何人讨论这个秘密。


读好写好

作家和程序员之间有一个有趣的相似之处。我认识的最好的作家都是狂热的读者。我认识的最好的程序员也花很多时间阅读代码。

不过,这并不奇怪,因为程序员是真正意义上的技术作家:他们通过向技术受众写作来交流技术思想。他们不写散文,而是编写计算机代码。

阅读代码可以帮助您:

  1. 改变你的观点:你会注意到你在写作时会错过的事情。
  2. 了解读者面临的障碍:作为一名作家,解决读者的问题至关重要。
  3. 把握大局:很容易让“作家的眼罩”。作为读者,您被迫处理更多的上下文。

与任何技术写作一样,通过代码交流技术思想需要一种深思熟虑的战略方法。只有通过磨练编写和阅读代码的技能才能提高这一点。


付诸实践

以下是您可以用来练习阅读代码的三个简短练习。他们每个人都需要十分钟或更短的时间。

#1 – 识别内部和外部负载

我是从 Felienne Hermans 的优秀著作《程序员的大脑》中了解到这个练习的。真是大开眼界。

在解决问题时,您的大脑会经历两种认知负荷:

  1. 内在负荷,源于问题本身的复杂性,以及
  2. 外部负载,由外部因素引起,例如实现细节。

为了说明差异并借用 Herman 的示例,请考虑以下 Python 函数:

 def function1(items): return [n for n in items if n > 10] def function2(items): above_ten = [] for n in items: if n > 10: above_ten.append(n)

这两个函数都解决了同一个问题:它们过滤了一个项目列表以仅包含大于 10 的项目。内在负载是相同的。

不过,额外负载取决于您的经验。对于不熟悉列表推导式的 Python 编码人员,即使可以毫无困难地生成function2 , function1也可能难以掌握。

您可以制作一个表格来识别函数中每一行代码的内在和外来负载。例如,这是在前面的示例中为function2填写的表格:

不要只写代码,也要阅读它!

我在她的书中使用了 Hermans 提供的模板,但您可以使用笔和纸或您选择的笔记应用程序轻松制作表格。

#2 – 绘制依赖关系图

从您不熟悉的代码库中选择一个功能并将其打印出来(或将代码保存为 PDF 或其他可以注释的数字格式)。然后圈出所有变量。

这个练习也来自 The Programmer’s Brain,但我从大学的第一堂编码课开始就一直在做。

例如,这里是练习 1 中的function2 ,所有变量都被圈起来了:

不要只写代码,也要阅读它!

接下来,绘制将变量的较早实例连接到下方或右侧实例的箭头:

不要只写代码,也要阅读它!

这可视化数据如何流经函数或其他代码,突出显示每一行如何依赖于前一行。

#3 – 调用树

从您不熟悉的代码库中选择一个函数,并绘制调用者及其每个被调用者进行的函数调用的层次结构。然后深入研究这些功能并执行相同的操作。

例如,下面是一个分析用户打字速度和准确性的Python 程序的调用树:

不要只写代码,也要阅读它!

调用树有多种用途。它向您展示了代码中使用的所有功能,因此您可以快速识别知识上的任何差距。该树还公开了代码的逻辑层次结构。您可以看到抽象层或缺乏抽象层,并了解它们如何相互作用。


继续阅读

了解认知科学如何帮助解释导致代码混乱的原因,以及简单的规则如何帮助您将混乱的代码转换为易于阅读和理解的清晰代码:

想要更简洁的代码?使用六法则

一个简单而强大的框架,用于消除混乱的代码。

不要只写代码,也要阅读它!对代码David Amos感到好奇

不要只写代码,也要阅读它!


深入挖掘

本期的三个练习中的每一个都可以在几分钟内完成。在接下来的两周内,每天花 10 或 20 分钟练习这些练习。在 GitHub 上查找一些代码或使用工作中的代码库。只要确保它是你以前没有读过的代码!


想要更多这样的东西吗?

每周六一封电子邮件,附上一条可行的提示。
总是少于 5 分钟的时间。

现在订阅

正在处理您的申请检查您的收件箱并确认您的订阅发送电子邮件时出错

原文: https://davidamos.dev/dont-just-write-code-read-it-too/

本站文章系自动翻译,站长会周期检查,如果有不当内容,请点此留言,非常感谢。
  • Abhinav
  • Abigail Pain
  • Adam Fortuna
  • Alberto Gallego
  • Alex Wlchan
  • Answer.AI
  • Arne Bahlo
  • Ben Carlson
  • Ben Kuhn
  • Bert Hubert
  • Bits about Money
  • Brian Krebs
  • ByteByteGo
  • Chip Huyen
  • Chips and Cheese
  • Christopher Butler
  • Colin Percival
  • Cool Infographics
  • Dan Sinker
  • David Walsh
  • Dmitry Dolzhenko
  • Dustin Curtis
  • Elad Gil
  • Ellie Huxtable
  • Ethan Marcotte
  • Exponential View
  • FAIL Blog
  • Founder Weekly
  • Geoffrey Huntley
  • Geoffrey Litt
  • Greg Mankiw
  • Henrique Dias
  • Hypercritical
  • IEEE Spectrum
  • Investment Talk
  • Jaz
  • Jeff Geerling
  • Jonas Hietala
  • Josh Comeau
  • Lenny Rachitsky
  • Liz Danzico
  • Lou Plummer
  • Luke Wroblewski
  • Matt Baer
  • Matt Stoller
  • Matthias Endler
  • Mert Bulan
  • Mostly metrics
  • News Letter
  • NextDraft
  • Non_Interactive
  • Not Boring
  • One Useful Thing
  • Phil Eaton
  • Product Market Fit
  • Readwise
  • ReedyBear
  • Robert Heaton
  • Ruben Schade
  • Sage Economics
  • Sam Altman
  • Sam Rose
  • selfh.st
  • Shtetl-Optimized
  • Simon schreibt
  • Slashdot
  • Small Good Things
  • Taylor Troesh
  • Telegram Blog
  • The Macro Compass
  • The Pomp Letter
  • thesephist
  • Thinking Deep & Wide
  • Tim Kellogg
  • Understanding AI
  • 英文媒体
  • 英文推特
  • 英文独立博客
©2025 搞英语 → 看世界 | Design: Newspaperly WordPress Theme