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

我的背景与 Cory 的对比

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

开发环境

• 操作系统：Ubuntu
  • 我原以为 Cory 是个 OS X 用户。
• 浏览器：Firefox
• IDE：PyCharm（我猜的）
  • 我从没用过 PyCharm，更习惯 VS Code。

模型

• 我开始担心自己会跟不上 Django 相关的内容了。
• Cory 展示了 ChatMessage 模型，它似乎是一个 ORM 对象，用来告诉框架如何把这个对象存入数据库以及如何从数据库中取回。
  • 这对我来说全是新东西，因为我从没用过 ORM。

迁移

• Cory 运行了命令 ./manage.py makemigrations chat，它似乎会生成一个数据库迁移，让他的数据库能够支持他刚定义的两个模型。
• 接着 Cory 运行 ./manage.py migrate 来执行刚才创建的迁移。
• Django 显然比我习惯的方式更“魔法”，因为我一直是手工编写数据库迁移的。
  • Cory 的做法远没有我每次定义新对象时都要写一大堆 SQL 样板代码那么繁琐，但它也在开发者与数据库之间增加了大量抽象层。

创建管理界面

• Cory 用 ChatGPT 基于他添加的模型生成了管理页面的样板定义代码。
  • ChatGPT 写得没错，但 Cory 需要稍作调整以符合他偏好的 Django 语法。

• 看起来 Django 会利用这些定义自动生成一个管理界面，用于在数据库中新增和编辑这些新模型。
  • 真不错。我做这种事的时候通常只能直接查询数据库，但这显然容易多了。

翻译

• Cory 似乎在设计这个应用时就考虑了可本地化性，这一点我已经大约 15 年没考虑过了。
• 国际化字符串的语法看起来相当直观。
  • {% translate "Manage your chats here." %}
  • 其他语言的翻译肯定得在别的地方提供，所以我很好奇那是怎么运作的。

Django 控制流

• Django 真奇怪！你可以直接调用 get_object_or_404，它似乎在找不到对象时会直接退出函数并返回一个 HTTP 404 错误。
  • 对于我这个从 Python Flask 或 Go 过来的人来说，这非常陌生——这两种语言都强制开发者更明确地返回 HTTP 错误（未处理的异常除外，它们会变成 HTTP 500 错误）。

git 图形界面

• Cory 使用了一个我从未见过的 git 图形界面工具。
  • 他是通过执行 git g 启动它的，我想这是 Cory 自己定义的 git 别名。
• Cory 在审查每个文件时逐个把它们加入提交。
• Cory 配置了一个 pre-commit 钩子，如果格式不正确就拒绝提交，然后自动把代码重新格式化为期望的风格。
  • 这种事我一直不敢做，因为我不信任自动化工具去改动我的代码。
  • 而 Cory 的做法是：自动化工具修改他的代码之后，他在提交前仍然会审查这些改动。

在客户端渲染与服务器端渲染之间共享代码

• Cory 似乎能用 htmx 解决一个一直困扰我的问题：如何避免在客户端渲染和服务器端渲染之间重复代码。

  • 在 Web 应用中，我经常遇到这样的情形：想往页面里添加内容，但又不想完全重新加载页面。
  • 如果用户刷新页面，他们应该看到与我们动态添加内容时相同的界面。
  • 我常常卡在三个都不理想的选项之间：
    1. 始终在客户端渲染内容，这样既复杂，浏览器中的渲染速度也更慢。
    2. 始终在服务器端渲染内容，这意味着我通常必须重新加载整个页面才能显示变更。
    3. 把渲染逻辑实现两遍：一遍用于客户端渲染，一遍用于服务器端渲染。

• 虽然视频里看得不够清楚，但看起来 htmx 让 Cory 在服务器端定义 HTML，然后 htmx 的属性能让某些元素自行重新渲染，既不需要整页刷新，也不需要 Cory 重新实现一遍渲染逻辑。

ChatGPT API

• ChatGPT API 出奇地好用。
  • 这个 API 只需要一个模型名称和一个对话消息列表。
  • 你通过在每次 API 调用时传入完整的对话历史来维护会话状态。

最后的想法

我本以为 Django 是个重量级框架，结果它比我想象的还要重。Django 为 Python 的列表、字典和枚举都有自己的一套封装。Django 与纯 Python 之间的距离，感觉就像 React 与原生 JavaScript 之间的鸿沟一样。

我很难把这些经验套用到自己的工作中，因为 Cory 做的很多事情都是 Django 特有的。也可能只是我选视频运气不好，因为这个视频里 Cory 做的工作主要是在把 Django 的各个组件粘合在一起。

不过，看到在一个从更高抽象层次设计一切的软件栈中开发是什么体验，还是挺有意思的。