STORYBOARD ・分鏡條—
這一站在做什麼
劇本圍讀畫完流程圖之後、正式議題進來之前,先用老師的範例把「一個專題怎麼從 0 到 1 長出來」走一遍。素材是課程 repo example/evolution/:第 0 幕是一支把抓、整理、存全做完的單體程式,第 6 幕是 Airflow 定時發任務給 Celery worker 的分散式架構。中間每一幕只改一件事,改完驗一次,驗的方式是「輸出跟上一幕一樣」。
這一站沒有新技術。Celery、RabbitMQ、Airflow 在課程手冊 03、04、12 都講過;這裡練的是拆解的順序與判準:哪一段程式該獨立成檔、為什麼 Celery 要排在很後面、每一步怎麼確認沒改壞。
七幕怎麼走
上方分鏡條點哪一幕,就看那一幕「做什麼、沒動什麼、怎麼驗」。金色積木是這一幕新長出來的,灰白是沒動的。
| 幕 | 做的事 | 沒動的東西 | 驗收 | repo 檔 |
|---|---|---|---|---|
| 0 | 起點,單體程式 | — | 程式可以執行,產生 CSV | step0_single_file.py |
| 1 | 同一支檔案內拆成抓、整理、存三個函式 | 檔案數量、儲存行為 | CSV 與 MySQL 的寫入結果和第 0 幕相同 | step1_functions.py |
| 2 | 同檔抽出一顆任務 crawl(stock_id, start, end) |
三個階段函式、檔案數量 | 輸出與第 1 幕相同;任務的三個可分散條件成立 | step2_task_in_file.py |
| 3 | 三個函式各自獨立成檔,設定抽到 config | 三個函式的內容 | 只改環境變數就能換儲存目標,client 與 transformer 不動 | step3_modules/ |
| 4 | task 與 producer 分家(crawl 搬檔、build_jobs 誕生) | client、transformer、repository、crawl 的內容 | 輸出與第 3 幕相同,此時仍未使用 Celery | step4_task/ |
| 5 | 接上 Celery 與 RabbitMQ | 任務函式的主體 | worker log 出現 task succeeded | step5_celery/ |
| 6 | Airflow 定時發任務 | 所有爬蟲相關程式 | DAG 的 task 變綠,worker log 出現任務紀錄 | step6_airflow/ |
每一幕怎麼算做完
- 把那一幕的檔案跑起來,拿到驗收欄寫的結果。
- 到專題地圖「前導七幕」節點勾那一幕;第 0、5、6 幕要交證據:終端機最後幾行、worker log 那一行、或 DAG 綠燈截圖。
- 七幕都勾完,節點通關 +20 專題 XP(一個節點一次)。
拆解的判準在資料館「補充 J」第二節:一段程式該不該獨立成檔,看它的輸入輸出能不能自足、有沒有共享狀態、能不能重跑。Celery 一定排在很後面,因為它換掉的是「誰來執行任務」,任務的邊界還沒切出來之前接它,出錯時分不清是拆解錯還是佇列設定錯。
七幕之外的兩件事
- 課程手冊 09 的 APScheduler 沒有出現在這條線上。它與 Airflow 在架構上同一個位置,都只回答「誰來呼叫 producer」;這條線每個位置只示範一種做法。
- 上雲不是第 7 幕。七幕做完,連線資訊都已經在 config 讀環境變數,換到雲端改的是環境變數的值,不是程式碼(手冊 14、16)。
之後怎麼用
Sprint 1 開工時,把你們的專題套回這七幕:第 2 幕要把程式切成「一個任務只做一件事」,你的那一件事是什麼、吃什麼輸入、一次處理幾筆。這一站最後一題就是先寫下這個答案(三行就好),Sprint 1 會回看。

送件鴿飛出去了