Takeaways from Cory Zue's May 2023 Livecoding Session

2023-06-03

Cory Zue 2023年5月直播编程的几点收获

原文由 Michael Lynch 于 2023-06-03 发布，订阅该博客

我的朋友Cory Zue一直在发布他的直播编程视频，于是我决定看一期并记下笔记。

我读过 Cory 博客的很多文章。我们都是 Python 开发者，但他专攻 Django，而我一直使用 Flask 这类更轻量的框架。我完全没有 Django 经验，不过对 Python 倒是很熟悉。

我开始担心自己会在 Django 相关的内容里迷路。
Cory 展示了 ChatMessage 模型，它似乎是一个 ORM 对象，用于告诉框架如何从数据库中存取对象。
- 这些对我来说都是全新的，因为我从没用过 ORM。

Cory 运行了命令 ./manage.py makemigrations chat，这似乎会生成一个数据库迁移，让数据库能够支持他刚刚定义的两个模型。
接着他又运行了 ./manage.py migrate 来执行刚刚创建的迁移。
Django 显然比我习惯的方式要“神奇”得多，因为我一直都是手动创建数据库迁移。
- Cory 的做法比起我每次定义新对象都要写一大堆 SQL 样板代码要省事得多，但也在开发者和数据库之间增加了一层厚厚的抽象。

Cory 用 ChatGPT 根据他新增的模型来生成管理页面的样板定义。
- ChatGPT 生成的结果是对的，但 Cory 还需要稍作调整，以符合他偏好的 Django 写法。

Cory 似乎在为这个应用做本地化设计，而我已经大概有 15 年没考虑过这个问题了。
可国际化字符串的语法看起来相当直观。
- {% translate "Manage your chats here." %}
- 肯定还得在别处提供其他语言的翻译，所以我很好奇这部分是怎么实现的。

Django 真奇怪！你可以直接调用 get_object_or_404，如果找不到对象，它似乎就会直接退出函数并返回 HTTP 404 错误。
- 这对习惯了 Python Flask 或 Go 的我来说很陌生，那两者都要求开发者更明确地返回 HTTP 错误（除了未处理的异常会被转为 HTTP 500 错误）。

Cory 用了一个我从没见过的 Git 图形界面。
- 他通过执行 git g 来启动它，我猜这是 Cory 自己设的 Git 别名。
他在复查时逐个将文件加入提交。
Cory 有一个 pre-commit 钩子，如果格式不正确就会拒绝提交，然后自动把代码格式化成所需的风格。
- 这是我一直不敢做的事，因为我不信任自动化工具来修改我的代码。
- 但 Cory 的做法是，让自动化工具先修改代码，然后他在提交前再复查一遍改动。

Cory 似乎能够用 htmx 解决一个一直困扰我的问题：如何在客户端渲染和服务端渲染之间避免代码重复。
- 在 Web 应用中，我经常会遇到想往页面添加内容，却又不想完全重载页面的情况。
- 如果用户刷新页面，他们应该看到与我们动态添加内容时相同的内容。
- 我常常在这三种都不理想的选择之间纠结：
  1. 始终在客户端渲染内容，这很复杂，而且在浏览器中渲染更慢。
  2. 始终在服务端渲染内容，这通常意味着要重载整个页面才能显示改动。
  3. 实现两套渲染逻辑：一套用于客户端渲染，一套用于服务端渲染。
视频里看得不太全，但似乎 htmx 让 Cory 可以在服务端定义 HTML，然后通过 htmx 属性让某些元素无需整页重载、也无需 Cory 重写渲染逻辑就能自行重新渲染。

ChatGPT API 用起来出乎意料地简单。
- API 只需要一个模型名称和对话中的消息列表。
- 你需要在每次 API 调用时传入完整的消息历史来维持对话状态。

我本以为 Django 是个重型框架，但它比我预想的还要重。Django 对 Python 的 list、dict 和 enum 都有自己的封装。Django 与原生 Python 之间的差距，感觉就像 React 与原生 JavaScript 之间的差距。

我很难把学到的东西应用到自己的工作中，因为 Cory 做的很多事情都是 Django 特有的。也可能只是我选的这期视频不太走运，因为他在视频里做的工作很大程度上是在把 Django 的各个部分粘合在一起。

不过，能看到在一个从更高抽象层级设计一切的技术栈中的开发体验，还是很有意思的。