本週發佈一個小東西

大多數困在教學迴圈中的人沒有技能問題。他們有發佈問題。你可以看四十小時的 Python 內容，但坐下來自己構建時仍然會凍結，因為教學課程為你移除了每個決定。這份指南是個強制函式：選擇一個小東西，完成它，在本週把它放在某人面前。

選擇一個你可以在週末完成的專案

這裡的失敗模式是範圍。人們認為他們的第一個專案應該是有身份驗證、計費和儀表板的 SaaS 應用。那是一個假扮週末專案的六個月專案。

反而選擇有單一清晰功能的東西：

• 一個根據 EXIF 日期重命名資料夾中檔案的 CLI 工具
• 一個爬取公開 API 並每天寄送摘要給你的指令碼
• 一個只有一個表單和一個輸出頁面的 Flask 應用
• 一個在你訪問的任何頁面上醒目標記關鍵字的瀏覽器擴充

寫程式碼前用一句話寫下範圍。如果句子需要「和」超過一次，就刪掉。「一個追蹤我的支出、也分類它們、也製作圖表的工具」是三個專案。先發佈追蹤器。

設定一個真實的期限和真實的受眾

沒有後果的期限不是期限。告訴一個朋友、在 Discord 伺服器上發文，或承諾週五時向同事展示。受眾比期限更重要——知道某人會真的看這個東西改變你的構建方式。你會停止過度設計架構，開始確保成功路徑真的能動。

給自己一個數字，而不是感覺。「當我有時間時我會做」產生不了任何東西。「今晚兩小時、明天兩小時、週六早上發佈」產生一個專案。

先構建醜陋版本

跳過資料夾結構爭論、跳過選擇 CSS 框架、跳過為只會儲存四十行的工具在 Postgres 和 SQLite 之間選擇。寫一個檔案。用 print() 敘述句而不是日誌程式。如果那是你需要的全部，用 Python 清單而不是資料庫。

# expenses.py - 醜陋版本，這很好
import csv
from datetime import date

def add_expense(amount, category):
    with open('expenses.csv', 'a', newline='') as f:
        writer = csv.writer(f)
        writer.writerow([date.today().isoformat(), amount, category])

add_expense(12.50, 'coffee')

那是一個可用的支出追蹤器。它不可擴展，沒有測試，它會讓你 90% 的方式走向明天你可以實際使用的東西。你可以重構一個可用的醜陋東西。你不能重構一個不存在的漂亮東西。

把它部署到某個地方，即使很粗糙

你筆電上的專案不算發佈。把它放在網際網路上或放在某人自己執行的地方。

• CLI 工具：推送到公開 GitHub 倉庫，包含一個顯示確切安裝和執行命令的兩段 README
• 網頁應用：部署到 Render、Fly.io 或一個 $5 的 DigitalOcean droplet——不要花三天比較一個只有一個用戶的專案的 Kubernetes 選項
• 指令碼：設定一個 cron 工作或 GitHub Action 所以它在你不接觸的情況下執行

部署摩擦殺死的副專案比任何技術挑戰都多。如果現在對你來說 git push 到像 Render 這樣的平台太多了，只要錄製一個 90 秒的 Loom 影片，顯示它在本地執行並發送那個。重點是外部證明它可用，而不是基礎結構成熟度。

寫下什麼破裂了

發佈後，花十五分鐘寫下三個出錯的東西和你如何修復它們。不是為了任何人——為了你。這是實際學習。教學課程教你語法。破裂的 pip install、CORS 錯誤、午夜的差一日期錯誤——那些教你軟體實際上如何表現。

把這些筆記保存在一個單一執行檔案中。在五或六個小專案之後，你會注意到相同類別的錯誤出現，那就是你的真實課程：教學課程從不涵蓋的差距。

然後選擇下一個東西，稍大一點

不要從 CLI 指令碼跳到分散式系統。一次加一個複雜度維度：下一個專案得到一個資料庫而不是 CSV、或一個基本測試套件、或一個第二個用戶。小的、複合的步驟打敗一個在第三週停滯的有野心的重寫。

如果你在這之後想要結構化後續步驟，Korra Studio 的 Python 和 DevOps 段落涵蓋了恰好在他們第一個發佈的專案之後傾向於讓人絆倒的部署和工具差距。