[编程感想] 2022年4月16日

April 16, 2022 · 4 min read

建议 Tips

您正在查看印刷版本的博客, 印刷版本的博客可能会缺少部分交互功能, 部分内容显示不全或过时. 如果您在查看该印刷版博客时遇到了任何问题, 欢迎来此链接查看在线版: https://www.kxxt.dev/blog/programming-thoughts/2022-04-16/

You are viewing a printed version of this blog. It may lack some interactive features and some content might now be fully displayed or outdated. If you encounter any problems while viewing this printed version of the blog, feel free to view the online version here: https://www.kxxt.dev/blog/programming-thoughts/2022-04-16/

最近在进行开发的时候, 总有一种感觉, 我感觉编程时很多知识是通过尝试来尝试出来的,而不是通过阅读文档得来的。我并不清楚这是我的个人体验还是很多人的共同感受。但是,经过思考,我发现这种方式存在着一些问题:

  • 通过尝试得来的知识有时是不准确的,甚至会造成非常严重的后果,一些 Implementation Details 可能会被人在尝试中发现,然后便加以利用,然而这些 Implementation Details 可能并没有在文档中被提及而且是实现者为了有更大的后续自由改动空间而刻意不在文档中提及的。这正如 Joel Spolsky 所说的那样:

    All non-trivial abstractions, to some degree, are leaky.

    这也让我想起了 Polkadot 在 2021 年发生的那次事故,因为 Rust 编译器的一个改动slice.binary_search_by() 从返回最后一个匹配改为可以返回任意一个匹配),导致 Polkadot 网络的共识机制产生问题

  • 还有一点就是,编程不想自然界那样,自然界的科学规律是未知的,我们人类通过实践建立科学模型去认识它们(当然,这些模型很可能也是不准确的,正如上一点所说,比如最近物理学的地基又裂了一道缝)。但是,编程领域的大部分东西都是 well-documented, 然而(不知道怎样去表达这种感情😂),我们却在使用很多“尝试”的方法去理解它们。

经过反思,我认为,偶尔的通过尝试去搞清楚 API 是如何工作的是没有问题的,毕竟很多时候试一试是很快的,这也是我喜欢 REPL 的原因,而翻看文档会花费更多的时间。然而,若自己长期的都去频繁地、重复地对一些非常 trivial 的特性去以“试”的方式去学习,那就应该怀疑一下自己是否缺乏在相应领域的系统性(但不一定要深入)学习了。除此之外,对于很多复杂的接口,使用 REPL 这种方式去了解如何去使用它恐怕会比查阅文档低效很多。比如你可能会通过尝试的方式来找出让 numpy 的某个有很多参数的复杂函数去执行自己想要的那个功能的方法,但是其实查阅一下文档在这时会更加方便。

  • REPL: read-eval-print-loop

参考资料: