我的朋友 Cory Zue 一直在公開他的直播寫程式過程，所以我決定挑一集來看看並把筆記記錄下來。

我的背景與 Cory 的背景

我讀過很多 Cory 部落格的文章。我們都是 Python 開發者，但他專精於 Django，而我則一直使用像 Flask 這類更輕量的框架。我完全沒有 Django 的經驗，不過對 Python 還算熟練。

開發環境

• OS：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 有一個 pre-commit hook，如果格式不正確就會擋下提交，然後把它重新格式化成期望的風格。
  • 這是我一直不敢做的事，因為我不太信任自動化工具去改我的程式碼。
  • 不過照 Cory 的做法，自動化工具雖然會改他的程式碼，但他在提交前還是會再檢查一次改動。

在客戶端與伺服器端渲染之間共用程式碼

• Cory 似乎能用 htmx 來解決一個一直困擾我的問題：如何在客戶端渲染與伺服器端渲染之間避免重複的程式碼。

  • 在網頁應用程式中，我常常遇到想在頁面上新增內容，卻又不想整個頁面重新載入的情況。
  • 如果使用者重新整理頁面，他們應該要看到跟我們動態新增內容時一樣的畫面。
  • 我常常卡在三個都不理想的選項之間：
    1. 永遠在客戶端渲染內容，這很複雜，而且在瀏覽器中渲染速度也比較慢。
    2. 永遠在伺服器端渲染內容，這表示我通常得重新載入整個頁面才能顯示變更。
    3. 把渲染邏輯實作兩次：一次給客戶端渲染，一次給伺服器端渲染。

• 影片中看得不夠清楚，但看起來 htmx 讓 Cory 可以在伺服器端定義他的 HTML，然後透過 htmx 的屬性讓某些元素自行重新渲染，不需要整頁重新載入，也不需要 Cory 重新實作渲染邏輯。

ChatGPT API

• ChatGPT API 出乎意料地簡單易用。
  • 這個 API 只需要一個模型名稱和對話中的訊息清單。
  • 每次呼叫 API 時，你只要把完整的對話紀錄傳給 ChatGPT，就能維持對話狀態。

最後心得

我本來就預期 Django 是個厚重的框架，但它比我想的還要更重。Django 甚至對 Python 的 list、dict 和 enum 都有自己的包裝。Django 與純 Python 之間的距離，感覺就像 React 與原生 JavaScript 之間的差距。

我很難把學到的東西套用到自己的工作中，因為 Cory 做的很多事情都是 Django 特有的。也可能只是我選的影片運氣不好，因為他在這支影片裡做的工作，很大一部分都是在把 Django 的不同元件黏合在一起。

不過，能看到在一個所有東西都從更高抽象層次來設計的技術堆疊中，開發體驗是什麼樣子，還是很有趣的。