相關文章：AI 讓寫作變輕鬆了？我可不這麼認為

你會把「和 ChatGPT 的對話、問答」寫成筆記嗎？顯然我會，而且很大量！

其中有 8 成以上都是程式相關，來自每天和 ChatGPT 的日常開發問答。

應該說，與 ChatGPT 對話早已成為我工作、學習的重要環節。在〈別依賴「試誤法」寫程式〉中我也強調過，像 ChatGPT 這樣的工具，如果僅僅用來「獲得答案」，未免也太可惜。

因此，我幾乎每天都會有新的「AI 對話筆記」。

話說回來，把 AI 的回答寫成筆記，並作為主要的知識來源，這是一個好的實踐嗎？

本文無法回答這個問題XD，但我可以分享一下，做了一年 AI 對話筆記後，我的看法與注意事項。

這是 Django Tutorial 的第 5 篇、DRF 系列的第 1 篇。

範例程式碼可參考我的 GitHub 專案。

終於要進入 Django API 的世界了！

不過，在開始 DRF 教學之前，我要先介紹 Django、DRF 兩者間的關係。

為什麼 Django 不乾脆自己實作 API 功能就好？而是把這個任務交給第三方套件，比如本文的 Django REST framework。

本文主旨

因此，本文的主要目標是：為讀者建立一個「high level」的世界觀。讓你了解為何在 Django 之外，我們還需要 Django REST framework。

了解兩者的關係，更能體會它們所扮演的不同角色。

簡言之，這一篇還沒有要開始寫 API。

系列：Django REST framework 教學

1. Django REST framework 教學（一）前言篇
2. 設定 Django REST framework 路由
3. 學習 Django REST framework 的 View 函式

在〈使用 Black 格式化程式碼——《Python 功力提升的樂趣》〉中，我們提到了「data」這個不佳的變數名稱。

以及應該要用什麼樣的名稱取代它，與例外可以使用 data 的情況。

看過那段後，你可以發現，data 雖爛，但還是偶有派上用場的時候。雖然絕大部分的情況，我依舊會避免使用。

然而有一個變數名稱，我絕對不會用。

比 data 更糟的變數名稱——result

當我遵守了好習慣，盡可能避免在程式碼中使用 data 命名後，本以為能從此過上幸福快樂的生活，但我錯了！

因為沒多久後我就發現，還有一個比 data 更駭人聽聞的變數名稱——result。

和 data 相比，其糟糕的程度，簡直有過之而無不及。畢竟萬事萬物都有「result」，因果循環、生生不息，而且這個命名更加抽象，令人不禁想問：

到底是什麼結果？

result 命名的濫用，在「儲存呼叫函式的結果」時最為常見，難怪到處都是 result。

作為一個 blog 創作者，我算是比較常編輯、翻修舊文的人。

編輯舊文往往需要花費不少時間，而且讀者也未必看得出有哪裡不同——所以我一定會在文章開頭備註、提醒☺️

部分文章，編輯過不止一次，比如〈Python 套件管理器——Poetry 完全入門指南〉，我將它視為代表作之一，編輯的次數應該是全站之最。

這樣的行為，雖然源於對文字與表達的追求，但其中也有實際的理由。

這篇來就分享一下，我考慮編輯舊文的三個實際理由。

這是 Django Tutorial 系列連載的第 4 篇。

範例程式碼可參考我的 GitHub 專案。

如〈Django Tutorial：系列介紹與導讀〉所言，這個系列主要是圍繞著「Django API」教學展開的。

但無論是用 Django 建立全端網站，還是開發 API，Django 的 HttpRequest——也就是我們熟悉的 request 參數——都是必不可少的元素。

HttpRequest 封裝了來自前端的 HTTP 請求，而 Django 會將 HttpRequest 物件自動帶入 view 函式的第一位置參數（通常就叫 request），讓我們可以直接使用。

為何需要了解 HttpRequest 物件

在我剛開始寫 Django 的時候，根本不太清楚 HttpRequest 具體有哪些屬性。

通常是看教學或為了實作某個功能而 Google 的時候，看到範例程式碼使用某個屬性，然後才知道這個屬性的存在。比如：

1
2
3
4

if request.method == "GET":
    do_something()
elif request.method == "POST":
    do_something_else()

看到這段，才知道 request 有一個 method 屬性。

這樣學當然可以，但如果一開始就對常用的 HttpRequest 屬性有基本了解，會讓你在學習 Django 的路上更加踏實。

今年 2 月下旬，我決定晚上（下班後）去圖書館讀書！

原因很簡單，我在家不好讀書，主要有兩點：

1. 如你所知，房間誘惑較多。不過這點其實還好，畢竟我工作、學習都是在家，所以不是主因。
2. 這才是主因，因為目前升降桌的燈光、螢幕都是為了「使用電腦」而設計，並不適合用來讀書。

以前我有兩張桌子，直接切換，一張專門用來讀書，那樣比較合乎實際。但換了升降桌後，小小的租屋空間就不夠了，不得不把「書桌」丟棄。

一直都有勉強試著讀書，但效果真的好差！

因為過程很麻煩，要先移開鍵盤，如果滑鼠沒放好，螢幕不時會被喚醒。檯燈我用的是 BenQ 的 ScreenBar，看螢幕很棒，但讀書的話，光源距離桌面又有點太遠了！而且角度也需要再調整。

讀個書猶如愚公移山，最後，我決定放棄苦苦掙扎，乖乖去圖書館！

想必你知道 Python 中有一個內建的特殊類別叫 Enum（來自 enum 模組），專門用來處理「列舉」態型的資料集合。

如同 collection 模組中的各種容器（比如：deque、Counter），Enum 已經定義好很多「內建特性（屬性、方法、行為）」供你使用。這些特性會讓你在處理特定情境時非常順手。

但是，這些特性也使得 Enum 類別與一般類別有著很大的差異，增加了學習門檻。

如你所見，Enum 的特性頗多，這讓人在學習、使用之前，難免有點望之卻步——至少我是這樣！

本文主旨與架構

本文分享我最近才開始把 Enum 應用在 API 開發中的經驗——從它的三大特性入手，並輔以一個實際問題情境。

Enum 的特性不少，但只要知曉這三件事，就可以在遇到「列舉」欄位時，善用 Enum 來提升開發效率，同時增進程式碼的簡潔與穩健。

不過話說回來，即使不是開發 API，也不影響你對本文的理解。只是我的經驗是從後端開發而來。

本文架構

為了讓你感受 Enum 的強大與美妙，本文的架構經過精心設計。共分為三個部分：

1. 問題情境：我會先提出一個問題情境，突顯舊方法的不足。
2. 然後再介紹 Enum 的三大特性，帶你進入 Enum 的世界。
3. 最後看 Enum 特性在問題情境中如何有效發揮，讓程式碼變得更加優雅——也就是它解決的痛點。

藉由這個流程，相信你對 Enum 會有更進一步的理解。