开发随笔 1

Posted on In Word count in article: 1.9k Reading time ≈ 7 mins.

序言

最近自学了很多课程，并且在开发很多项目，因此没有写博文。鉴于博客要经常更新，我决定写另一种形式的博文——开发随笔——来记录开发过程中的所见所思。本文包含以下内容：选择第三方库、Go、八股文。

选择第三方库

为了让项目实现某项功能，我们通常选择现有的第三方库，避免重复造轮子。当有很多第三方库时，我们常常会陷入选择困难，不知道选哪个好。我总结了自己在选择第三方库时的一些考虑（要素不分先后，要综合考虑）：

  • 开源：通常来说，开源 >> 闭源，但是也不绝对。一些不怎么更新的开源库可能不再适配，亦或是被提交恶意代码。闭源的商业产品可能非常优秀，且价格合适，性价比很高，相比开源产品能够节省大量时间。
  • Star 数量：这个指标非常有迷惑性。一方面，我们倾向于认为有最多 Stars 的就是最好的，统计数据的确可以印证这一点。另一方面，一个库的 Star 数量高可能来自于非技术性的原因，比如作者更会宣传、人为买 Stars。
  • 功能：该库是否包含我们需要的功能？它提供的选项是否完备、丰富？是否存在很多提 bug 的 Issue？
  • 文档：文档是否详细、全面、及时更新、能看得懂？
  • 活跃度：从提交频率、Issue close 频率、PR merge/reject 频率、发布频率等多方面判断。
  • 安全性：是否被曝出过重大安全漏洞？
  • 可持续性：作者未来是否会继续开发这个库？除非作者明确写了不再准备支持、或是这个库进入维护阶段，需要从其他的方面来推测该方面，比如作者其他的库。
  • 第三方平台上的评价：参考 Reddit、Stack Overflow、B 站等平台对这个库的讨论。注意区分利益相关者、网络水军等不公正的评价。
  • 相关新闻：正面或是负面的都可以作为参考，甚至可以搜索作者的相关新闻。
  • 政治内容：包含政治内容的一律不用。

以上方面或多或少包含在“生态”和“社区”这两个词中，但是我不想使用大概念而是想尽可能具体地描述。

Go

MIT 6.824 需要使用 Go 语言写项目，于是我开始学习 Go。两年前我曾接触过 Go，觉得这门语言很“抽象”。而在学习了 JS 和一些前端库后，我对于 Go 的印象发生了改变。

Go 的很多理念与 JS 类似，比如函数是一等公民、没有原生的面向对象支持。之前我只熟悉 Java ，所以对于 Go 的这套理念感觉莫名其妙，仿佛只有 Go 特例独行。在深入学习了 JS 后，觉得这些理念很好接受。

另一个曾经让我觉得 Go 很奇怪、难以接受的是它的语法及其背后的设计理念。Go 在语法上几乎不允许任何的 alternative：有了 for，就不允许有 while 和 do-while；既然有 if，那么三元运算符 bool ? v1 : v2 就没必要存在了。当然，我当时也理解这么做的好处 —— 在语言层面就让所有开发者遵守同一套规范。但是我始终有些难以接受：Go 是否太专制了？

让我们先看看别的语言是怎么做的。Spring Boot 的设计原则是“约定大于配置”，提供了很多开箱即用的功能。我们只有遵循这些约定才能快速开发，否则得手动配置。但是，Spring Boot 至少提供了自由配置的余地，我们完全可以不遵守默认配置，搞一套我们自己的规则。与之不同，Redux Toolkit、Next.js 非常 opinionated（固执己见的、顽固的），我们必须遵守它们的约定/规则，几乎没有配置的余地（就算可以配置，也极其麻烦）。

再回到 Go，由于学过了 RTK、Next.js，我现在对于其语法的唯一性可以接受了：Go 是一款 opinionated 的编程语言。注意，opinionated 不见得是坏事，就像第三方库太多导致的选择困难症，有大厂背书的编程规则反而减轻了我们花费在对比不同方案上的时间成本，提高了效率。

从这两方面可以看出，多学点东西总是有好处的，可以培养自己的技术积累，也更能接受新技术。

八股文

什么是八股文？DeepSeek 的回答如下：

在计算机领域，“八股文” 这个词是一个带有贬义的比喻，它指的是那些僵化、套路化、脱离实际、过分注重形式而忽视实质内容的知识点、答题方式或面试风格。

面试八股文： 指那些在技术面试中被反复问到、要求候选人必须准确背诵的标准答案式问题。

的确，谈到八股，很多人都是负面评价，但是又不得不背，不然无法通过技术面试。值得注意的是，这些问题本身并没有错，相反，它们是理解某一个领域很好的入口，因为大部分都是基础性、底层性的问题。

注意，我说的好的八股文是作者精心整理后的，比如小林 coding，而不是随便在网上抄一抄就发一篇博文的。后者在网上一搜一大把，且内容同质化严重。

引起我对于八股文态度反思的是我在项目中使用 SQLite 事务。由于我不熟悉 SQLite 事务模型和并发模型，我担心产生死锁，便上网查找相关文档。国内有用的资料不多，一些有用的资料也存在大量重复，让我怀疑其真实性。而官方文档我没太看明白。最终，我通过 LLM 解决了疑惑，但是没有对于 SQLite 的整体架构有深入了解。

你可能会问：为什么我不直接问 LLM 呢？答案是：如果网上不存在有价值的 SQLite 资料，LLM 是如何训练得能够准确回答 SQLite 的问题的呢？它难道不会产生幻觉，给我一个错误答案吗？之前我问 WPF 相关问题时就碰到过幻觉。

与之相对，MySQL 的八股文到处都是。我们既可以自己看，也可以相对放心地让 LLM 替我们总结。这也是为什么我期待网上有 SQLite 的八股文可供参考。

最后，抛开“八股文”这个贬义的称呼不谈，秉持凡是“能够帮我们扩展一个逻辑的边界的问题，就是好问题”的理念，在我们学会使用一个技术后、想要深入钻研时，八股文以 FAQ 的形式为我们提供了一条有别于官方文档和读源码的道路，这是一件好事。况且不少人还靠着八股文拿到了 offer，没必要过河拆桥。