3步拆解做章源碼解析解決新手搭項目難
剛啃完 Python 基礎(chǔ)語法，對著空白的 IDE 發(fā)呆？代碼會寫，項目卻搭不起來？別慌，這不是你笨，是缺了“做章”這一步。很多新人卡在“語法孤島”，不知道如何把零散的知識點組裝成可運行的系統(tǒng)。今天咱們不背八股文，直接上做章，通過源碼解析把項目骨架搭起來，讓你從“寫腳本”進階到“做工程”。
一、 做章本質(zhì)：從離散到連續(xù)的工程化
1. 為什么你會覺得“難”？
新手最大的誤區(qū)，是把“編程”當成“拼積木”。以為學會了 if-else 和 for 循環(huán)，就能直接寫出一個電商網(wǎng)站或后臺管理系統(tǒng)。
現(xiàn)實是：語法只是磚頭，做章才是圖紙。
“做章”在這里，我們定義為模塊化章節(jié)構(gòu)建（Chapter/Module Construction）。它不是指排版，而是指如何將業(yè)務(wù)邏輯拆分為高內(nèi)聚、低耦合的模塊，并建立它們之間的通信機制。
很多教程只教 print(Hello World)，卻不教你怎么組織文件結(jié)構(gòu)。當你有了 10 個文件時，你開始困惑：user.py 里要調(diào)用 database.py，而 database.py 又依賴 config.py，這個依賴關(guān)系怎么理？
這就是做章要解決的核心問題：依賴管理與邊界定義。
2. 權(quán)威背書：RFC 7519 與結(jié)構(gòu)規(guī)范
別覺得這是程序員拍腦袋想的。在計算機通信領(lǐng)域，RFC 規(guī)范（Request for Comments）早就定義了數(shù)據(jù)結(jié)構(gòu)的標準。
比如 RFC 7519 (JSON Web Token, JWT)。它規(guī)定了 Token 必須分為 Header、Payload、Signature 三部分，用 . 分隔。
做章的邏輯與此異曲同工：Header（頭部）：定義模塊的元數(shù)據(jù)（如：這是用戶模塊，版本 v1.0）。
Payload（負載）：核心業(yè)務(wù)邏輯（如：登錄、注冊函數(shù)）。
Signature（簽名）：接口契約（如：輸入?yún)?shù)類型，輸出結(jié)果類型）。當你按照這種“三段式”思維去拆解代碼，項目瞬間就有了秩序感。
二、 類比解釋：像寫小說一樣做章
1. 小說結(jié)構(gòu) vs 項目結(jié)構(gòu)
想象你在寫一本小說，而不是寫代碼。語法：是詞匯和句子。你會寫“他打開了門”，這沒問題。
做章：是章節(jié)大綱。第一章“相遇”，第二章“沖突”，第三章“高潮”。
項目：是整本書。新手失敗的原因，是試圖跳過大綱直接寫正文。今天寫一句“用戶登錄”，明天寫一句“數(shù)據(jù)庫連接”，后天發(fā)現(xiàn)登錄邏輯依賴數(shù)據(jù)庫，但數(shù)據(jù)庫代碼還沒寫，或者寫在了一個奇怪的角落。
做章，就是先畫大綱。
在代碼世界里，“章”對應(yīng)的是 Package（包） 或 Module（模塊）。
2. 核心原則：單一職責與清晰邊界
每一章（模塊）必須只干一件事。auth 章：只管身份驗證。
db 章：只管數(shù)據(jù)存取。
api 章：只管對外接口。如果 auth 章里直接寫了 SQL 語句，那就亂了章法。讀者（或未來的你）無法快速定位問題。
源碼解析視角：
優(yōu)秀的開源項目（如 Django, FastAPI）之所以易維護，就是因為它們的目錄結(jié)構(gòu)就是“章節(jié)目錄”。打開根目錄，你看到的不是雜亂的文件，而是清晰的功能分區(qū)。
三、 源碼/偽代碼片段：實戰(zhàn)拆解
1. 錯誤的寫法：一鍋粥
先看一段典型的“新手代碼”，沒有做章，所有邏輯堆在 main.py：
# main.py - 典型的反模式
import sqlite3def login():# 數(shù)據(jù)庫連接邏輯混在這里conn = sqlite3.connect('app.db')cur = conn.cursor()cur.execute(SELECT * FROM users WHERE name='admin')user = cur.fetchone()# 業(yè)務(wù)邏輯混在這里if user:print(登錄成功)return Trueelse:print(用戶不存在)return Falsedef show_users():# 又是數(shù)據(jù)庫連接conn = sqlite3.connect('app.db')cur = conn.cursor()cur.execute(SELECT name FROM users)for row in cur.fetchall():print(row)# 直接運行
if __name__ == __main__:login()show_users()問題在哪？重復(fù)代碼：數(shù)據(jù)庫連接邏輯寫了兩遍。
耦合嚴重：如果數(shù)據(jù)庫從 SQLite 換成 MySQL，你要改兩個地方。
無法測試：你想單獨測試 login 邏輯，必須連上真實的數(shù)據(jù)庫。
擴展困難：加個“找回密碼”功能，文件會無限膨脹。2. 正確的寫法：做章 + 源碼解析
我們將上述邏輯拆分為三個“章”（模塊）：db、auth、api。
目錄結(jié)構(gòu)：
project/
├── main.py # 入口，只做調(diào)度
├── db/ # 數(shù)據(jù)訪問章
│ ├── __init__.py
│ └── connector.py
├── auth/ # 身份認證章
│ ├── __init__.py
│ └── service.py
└── api/ # 接口定義章├── __init__.py└── routes.pyStep 1: 數(shù)據(jù)訪問章 (db/connector.py)
這一章只負責“連接”和“執(zhí)行”，不關(guān)心業(yè)務(wù)。
import sqlite3class DBConnector:def __init__(self, db_path='app.db'):self.db_path = db_pathself.conn = Nonedef connect(self):# 封裝連接邏輯self.conn = sqlite3.connect(self.db_path)return self.conndef execute(self, query, params=None):if not self.conn:self.connect()cursor = self.conn.cursor()if params:cursor.execute(query, params)else:cursor.execute(query)return cursordef close(self):if self.conn:self.conn.close()Step 2: 身份認證章 (auth/service.py)
這一章只負責“驗證”，它依賴 db 章，但不關(guān)心 db 怎么連的。
from db.connector import DBConnectorclass AuthService:def __init__(self):self.db = DBConnector()def verify_user(self, username: str) - bool:# 調(diào)用 db 章的能力cursor = self.db.execute(SELECT 1 FROM users WHERE name = ?, (username,))result = cursor.fetchone()# 純業(yè)務(wù)邏輯判斷if result:return Truereturn Falsedef cleanup(self):self.db.close()Step 3: 入口調(diào)度 (main.py)
入口文件變得非常干凈，只負責“講故事”的流程。
from auth.service import AuthServicedef main():# 實例化服務(wù)auth_service = AuthService()try:# 模擬 API 請求print(--- 嘗試登錄 ---)is_logged_in = auth_service.verify_user(admin)if is_logged_in:print(Access Granted)else:print(Access Denied)finally:# 確保資源釋放auth_service.cleanup()if __name__ == __main__:main()3. 逐行解析：做章帶來的價值依賴單向性：main 依賴 auth，auth 依賴 db。箭頭永遠指向底層，沒有循環(huán)依賴。
可替換性：如果明天要把 sqlite3 換成 mysql-connector，你只需要修改 db/connector.py，其他代碼一行都不用改。這就是做章的威力。
可測試性：你可以寫一個 MockDB 類，在測試 auth 時，不需要真實數(shù)據(jù)庫，直接注入 MockDB。四、 流程描述：從需求到落地的四步法
掌握做章，需要一套標準的思維流程。我稱之為 D-R-S-T 模型。
1. Decompose (拆解)
拿到需求（比如“做一個用戶登錄系統(tǒng)”），先不要寫代碼。
問自己：需要哪些數(shù)據(jù)？（用戶表）
需要哪些動作？（查詢、驗證）
需要哪些入口？（CLI 或 Web API）將系統(tǒng)拆分為 數(shù)據(jù)層、業(yè)務(wù)層、表現(xiàn)層。
2. Role-Define (定義角色/接口)
為每個“章”定義接口。db 章必須提供 execute 方法。
auth 章必須提供 verify_user 方法。
關(guān)鍵：先寫接口（函數(shù)簽名），再寫實現(xiàn)。這就像先寫小說大綱，再填內(nèi)容。3. Structure (構(gòu)建結(jié)構(gòu))
創(chuàng)建文件夾和文件。遵循 PEP 8 規(guī)范。
使用 __init__.py 明確包邊界。
配置文件（如 config.py）單獨放一章，避免硬編碼。4. Test Iterate (測試與迭代)
每完成一個“章”，就運行一次。先測 db：能連上數(shù)據(jù)庫嗎？
再測 auth：能查出用戶嗎？
最后測 main：流程通了嗎？避坑指南：坑1：上帝對象。一個類做了所有事。解：拆分。如果類超過 200 行，考慮拆分?？?：全局變量。到處 import 一個全局配置。解：使用依賴注入（DI）或單例模式，通過參數(shù)傳遞配置。坑3：過早優(yōu)化。剛開始就寫復(fù)雜的緩存策略。解：先跑通流程，再優(yōu)化性能。做章初期，清晰度 性能。五、 實戰(zhàn)驗證：一個更復(fù)雜的案例
假設(shè)我們要做一個“博客系統(tǒng)”，涉及文章、評論、用戶。
錯誤做法：
article.py 里直接寫評論邏輯，user.py 里直接寫文章邏輯?；ハ?import，亂成一團。
做章做法：Model 章 (models/)user.py: 定義 User 數(shù)據(jù)結(jié)構(gòu)。
post.py: 定義 Post 數(shù)據(jù)結(jié)構(gòu)。
原則：純數(shù)據(jù)，無邏輯。Repository 章 (repos/)user_repo.py: 專門負責 User 的 CRUD。
post_repo.py: 專門負責 Post 的 CRUD。
原則：只跟數(shù)據(jù)庫打交道，返回 Model 對象。Service 章 (services/)blog_service.py: 組合 User 和 Post。
邏輯：get_user_posts(user_id) 調(diào)用 post_repo。
原則：業(yè)務(wù)規(guī)則在這里。比如“只有作者能刪文章”。Controller 章 (controllers/)api.py: 接收 HTTP 請求，調(diào)用 Service，返回 JSON。
原則：無業(yè)務(wù)邏輯，只做參數(shù)校驗和響應(yīng)格式化。源碼解析對比：
# services/blog_service.py
class BlogService:def __init__(self, post_repo, user_repo):# 依賴注入：Service 不創(chuàng)建 Repo，而是接收它self.post_repo = post_repoself.user_repo = user_repodef get_user_posts(self, user_id):# 業(yè)務(wù)邏輯：查詢該用戶的所有文章posts = self.post_repo.find_by_user_id(user_id)# 業(yè)務(wù)邏輯：過濾掉已刪除的return [p for p in posts if not p.is_deleted]注意這里的 __init__，我們沒有在 Service 里 import 并 new 一個 Repo，而是通過參數(shù)傳入。
這就是做章的高級技巧：解耦。
這樣，我在測試 BlogService 時，可以傳入一個 FakePostRepo（內(nèi)存模擬數(shù)據(jù)），完全不需要數(shù)據(jù)庫。
六、 進階技巧與常見違規(guī)問題
1. 命名即文檔
文件名、函數(shù)名必須體現(xiàn)“章”的職責。壞名字：utils.py (里面啥都有)
好名字：date_utils.py, string_utils.py
壞函數(shù)：do_stuff()
好函數(shù)：calculate_total_price()2. 避免循環(huán)導入
如果 A 章 import B 章，B 章又 import A 章，Python 會報錯。原因：依賴混亂，職責重疊。
解決：提取公共部分到 C 章，A 和 B 都依賴 C。
使用 TYPE_CHECKING 進行類型提示導入（僅用于靜態(tài)檢查，不實際運行）。3. 配置管理
不要在代碼里寫 db_host = localhost。
建立 config 章：
# config/settings.py
import osclass Settings:DB_HOST = os.getenv('DB_HOST', 'localhost')DB_PORT = int(os.getenv('DB_PORT', 5432))SECRET_KEY = os.getenv('SECRET_KEY', 'dev-key')所有其他章從 config 章讀取配置。
4. 日志規(guī)范
每個章應(yīng)該有獨立的 Logger。
logging.getLogger('db.connector')
這樣在排查問題時，可以單獨開啟 db 章的 DEBUG 日志，而不會淹沒在其他日志里。
七、 總結(jié)與互動
做章，本質(zhì)上是一種工程思維的體現(xiàn)。它強迫你在動手寫代碼前，先思考系統(tǒng)的結(jié)構(gòu)和邊界。
核心回顧：做章 = 模塊化。高內(nèi)聚，低耦合。
源碼解析是手段，目的是理解依賴關(guān)系。
D-R-S-T 流程：拆解、定義、構(gòu)建、測試。
依賴注入是解耦的關(guān)鍵工具。當你掌握了做章，你會發(fā)現(xiàn)，無論是 100 行的腳本，還是 10 萬行的微服務(wù)，底層邏輯是一樣的：分而治之，各司其職。
不要害怕重構(gòu)。剛開始項目小，全寫在一個文件里沒問題。但當文件超過 500 行，或者你開始修改一個地方導致另一個地方報錯時，就是做章的最佳時機。
最后，拋出一個問題引發(fā)討論：
在你們的實際項目中，是傾向于**“先寫完功能再重構(gòu)做章”，還是“先設(shè)計好章節(jié)結(jié)構(gòu)再填代碼”**？
哪種方式讓你踩的坑更少？或者你有沒有遇到過因為“不做章”導致的慘痛教訓？
你更常用哪種寫法？評論區(qū)交流，咱們一起避坑。 3步拆解做章源碼解析解決新手搭項目難
3步拆解做章源碼解析解決新手搭項目難
剛啃完 Python 基礎(chǔ)語法，對著空白的 IDE 發(fā)呆？代碼會寫，項目卻搭不起來？別慌，這不是你笨，是缺了“做章”這一步。很多新人卡在“語法孤島”，不知道如何把零散的知識點組裝成可運行的系統(tǒng)。今天咱們不背八股文，直接上做章，通過源碼解析把項目骨架搭起來，讓你從“寫腳本”進階到“做工程”。
一、 做章本質(zhì)：從離散到連續(xù)的工程化
1. 為什么你會覺得“難”？
新手最大的誤區(qū)，是把“編程”當成“拼積木”。以為學會了 if-else 和 for 循環(huán)，就能直接寫出一個電商網(wǎng)站或后臺管理系統(tǒng)。
現(xiàn)實是：語法只是磚頭，做章才是圖紙。
“做章”在這里，我們定義為模塊化章節(jié)構(gòu)建（Chapter/Module Construction）。它不是指排版，而是指如何將業(yè)務(wù)邏輯拆分為高內(nèi)聚、低耦合的模塊，并建立它們之間的通信機制。
很多教程只教 print(Hello World)，卻不教你怎么組織文件結(jié)構(gòu)。當你有了 10 個文件時，你開始困惑：user.py 里要調(diào)用 database.py，而 database.py 又依賴 config.py，這個依賴關(guān)系怎么理？
這就是做章要解決的核心問題：依賴管理與邊界定義。
2. 權(quán)威背書：RFC 7519 與結(jié)構(gòu)規(guī)范
別覺得這是程序員拍腦袋想的。在計算機通信領(lǐng)域，RFC 規(guī)范（Request for Comments）早就定義了數(shù)據(jù)結(jié)構(gòu)的標準。
比如 RFC 7519 (JSON Web Token, JWT)。它規(guī)定了 Token 必須分為 Header、Payload、Signature 三部分，用 . 分隔。
做章的邏輯與此異曲同工：Header（頭部）：定義模塊的元數(shù)據(jù)（如：這是用戶模塊，版本 v1.0）。
Payload（負載）：核心業(yè)務(wù)邏輯（如：登錄、注冊函數(shù)）。
Signature（簽名）：接口契約（如：輸入?yún)?shù)類型，輸出結(jié)果類型）。當你按照這種“三段式”思維去拆解代碼，項目瞬間就有了秩序感。
二、 類比解釋：像寫小說一樣做章
1. 小說結(jié)構(gòu) vs 項目結(jié)構(gòu)
想象你在寫一本小說，而不是寫代碼。語法：是詞匯和句子。你會寫“他打開了門”，這沒問題。
做章：是章節(jié)大綱。第一章“相遇”，第二章“沖突”，第三章“高潮”。
項目：是整本書。新手失敗的原因，是試圖跳過大綱直接寫正文。今天寫一句“用戶登錄”，明天寫一句“數(shù)據(jù)庫連接”，后天發(fā)現(xiàn)登錄邏輯依賴數(shù)據(jù)庫，但數(shù)據(jù)庫代碼還沒寫，或者寫在了一個奇怪的角落。
做章，就是先畫大綱。
在代碼世界里，“章”對應(yīng)的是 Package（包） 或 Module（模塊）。
2. 核心原則：單一職責與清晰邊界
每一章（模塊）必須只干一件事。auth 章：只管身份驗證。
db 章：只管數(shù)據(jù)存取。
api 章：只管對外接口。如果 auth 章里直接寫了 SQL 語句，那就亂了章法。讀者（或未來的你）無法快速定位問題。
源碼解析視角：
優(yōu)秀的開源項目（如 Django, FastAPI）之所以易維護，就是因為它們的目錄結(jié)構(gòu)就是“章節(jié)目錄”。打開根目錄，你看到的不是雜亂的文件，而是清晰的功能分區(qū)。
三、 源碼/偽代碼片段：實戰(zhàn)拆解
1. 錯誤的寫法：一鍋粥
先看一段典型的“新手代碼”，沒有做章，所有邏輯堆在 main.py：
# main.py - 典型的反模式
import sqlite3def login():# 數(shù)據(jù)庫連接邏輯混在這里conn = sqlite3.connect('app.db')cur = conn.cursor()cur.execute(SELECT * FROM users WHERE name='admin')user = cur.fetchone()# 業(yè)務(wù)邏輯混在這里if user:print(登錄成功)return Trueelse:print(用戶不存在)return Falsedef show_users():# 又是數(shù)據(jù)庫連接conn = sqlite3.connect('app.db')cur = conn.cursor()cur.execute(SELECT name FROM users)for row in cur.fetchall():print(row)# 直接運行
if __name__ == __main__:login()show_users()問題在哪？重復(fù)代碼：數(shù)據(jù)庫連接邏輯寫了兩遍。
耦合嚴重：如果數(shù)據(jù)庫從 SQLite 換成 MySQL，你要改兩個地方。
無法測試：你想單獨測試 login 邏輯，必須連上真實的數(shù)據(jù)庫。
擴展困難：加個“找回密碼”功能，文件會無限膨脹。2. 正確的寫法：做章 + 源碼解析
我們將上述邏輯拆分為三個“章”（模塊）：db、auth、api。
目錄結(jié)構(gòu)：
project/
├── main.py # 入口，只做調(diào)度
├── db/ # 數(shù)據(jù)訪問章
│ ├── __init__.py
│ └── connector.py
├── auth/ # 身份認證章
│ ├── __init__.py
│ └── service.py
└── api/ # 接口定義章├── __init__.py└── routes.pyStep 1: 數(shù)據(jù)訪問章 (db/connector.py)
這一章只負責“連接”和“執(zhí)行”，不關(guān)心業(yè)務(wù)。
import sqlite3class DBConnector:def __init__(self, db_path='app.db'):self.db_path = db_pathself.conn = Nonedef connect(self):# 封裝連接邏輯self.conn = sqlite3.connect(self.db_path)return self.conndef execute(self, query, params=None):if not self.conn:self.connect()cursor = self.conn.cursor()if params:cursor.execute(query, params)else:cursor.execute(query)return cursordef close(self):if self.conn:self.conn.close()Step 2: 身份認證章 (auth/service.py)
這一章只負責“驗證”，它依賴 db 章，但不關(guān)心 db 怎么連的。
from db.connector import DBConnectorclass AuthService:def __init__(self):self.db = DBConnector()def verify_user(self, username: str) - bool:# 調(diào)用 db 章的能力cursor = self.db.execute(SELECT 1 FROM users WHERE name = ?, (username,))result = cursor.fetchone()# 純業(yè)務(wù)邏輯判斷if result:return Truereturn Falsedef cleanup(self):self.db.close()Step 3: 入口調(diào)度 (main.py)
入口文件變得非常干凈，只負責“講故事”的流程。
from auth.service import AuthServicedef main():# 實例化服務(wù)auth_service = AuthService()try:# 模擬 API 請求print(--- 嘗試登錄 ---)is_logged_in = auth_service.verify_user(admin)if is_logged_in:print(Access Granted)else:print(Access Denied)finally:# 確保資源釋放auth_service.cleanup()if __name__ == __main__:main()3. 逐行解析：做章帶來的價值依賴單向性：main 依賴 auth，auth 依賴 db。箭頭永遠指向底層，沒有循環(huán)依賴。
可替換性：如果明天要把 sqlite3 換成 mysql-connector，你只需要修改 db/connector.py，其他代碼一行都不用改。這就是做章的威力。
可測試性：你可以寫一個 MockDB 類，在測試 auth 時，不需要真實數(shù)據(jù)庫，直接注入 MockDB。四、 流程描述：從需求到落地的四步法
掌握做章，需要一套標準的思維流程。我稱之為 D-R-S-T 模型。
1. Decompose (拆解)
拿到需求（比如“做一個用戶登錄系統(tǒng)”），先不要寫代碼。
問自己：需要哪些數(shù)據(jù)？（用戶表）
需要哪些動作？（查詢、驗證）
需要哪些入口？（CLI 或 Web API）將系統(tǒng)拆分為 數(shù)據(jù)層、業(yè)務(wù)層、表現(xiàn)層。
2. Role-Define (定義角色/接口)
為每個“章”定義接口。db 章必須提供 execute 方法。
auth 章必須提供 verify_user 方法。
關(guān)鍵：先寫接口（函數(shù)簽名），再寫實現(xiàn)。這就像先寫小說大綱，再填內(nèi)容。3. Structure (構(gòu)建結(jié)構(gòu))
創(chuàng)建文件夾和文件。遵循 PEP 8 規(guī)范。
使用 __init__.py 明確包邊界。
配置文件（如 config.py）單獨放一章，避免硬編碼。4. Test Iterate (測試與迭代)
每完成一個“章”，就運行一次。先測 db：能連上數(shù)據(jù)庫嗎？
再測 auth：能查出用戶嗎？
最后測 main：流程通了嗎？避坑指南：坑1：上帝對象。一個類做了所有事。解：拆分。如果類超過 200 行，考慮拆分?？?：全局變量。到處 import 一個全局配置。解：使用依賴注入（DI）或單例模式，通過參數(shù)傳遞配置。坑3：過早優(yōu)化。剛開始就寫復(fù)雜的緩存策略。解：先跑通流程，再優(yōu)化性能。做章初期，清晰度 性能。五、 實戰(zhàn)驗證：一個更復(fù)雜的案例
假設(shè)我們要做一個“博客系統(tǒng)”，涉及文章、評論、用戶。
錯誤做法：
article.py 里直接寫評論邏輯，user.py 里直接寫文章邏輯?；ハ?import，亂成一團。
做章做法：Model 章 (models/)user.py: 定義 User 數(shù)據(jù)結(jié)構(gòu)。
post.py: 定義 Post 數(shù)據(jù)結(jié)構(gòu)。
原則：純數(shù)據(jù)，無邏輯。Repository 章 (repos/)user_repo.py: 專門負責 User 的 CRUD。
post_repo.py: 專門負責 Post 的 CRUD。
原則：只跟數(shù)據(jù)庫打交道，返回 Model 對象。Service 章 (services/)blog_service.py: 組合 User 和 Post。
邏輯：get_user_posts(user_id) 調(diào)用 post_repo。
原則：業(yè)務(wù)規(guī)則在這里。比如“只有作者能刪文章”。Controller 章 (controllers/)api.py: 接收 HTTP 請求，調(diào)用 Service，返回 JSON。
原則：無業(yè)務(wù)邏輯，只做參數(shù)校驗和響應(yīng)格式化。源碼解析對比：
# services/blog_service.py
class BlogService:def __init__(self, post_repo, user_repo):# 依賴注入：Service 不創(chuàng)建 Repo，而是接收它self.post_repo = post_repoself.user_repo = user_repodef get_user_posts(self, user_id):# 業(yè)務(wù)邏輯：查詢該用戶的所有文章posts = self.post_repo.find_by_user_id(user_id)# 業(yè)務(wù)邏輯：過濾掉已刪除的return [p for p in posts if not p.is_deleted]注意這里的 __init__，我們沒有在 Service 里 import 并 new 一個 Repo，而是通過參數(shù)傳入。
這就是做章的高級技巧：解耦。
這樣，我在測試 BlogService 時，可以傳入一個 FakePostRepo（內(nèi)存模擬數(shù)據(jù)），完全不需要數(shù)據(jù)庫。
六、 進階技巧與常見違規(guī)問題
1. 命名即文檔
文件名、函數(shù)名必須體現(xiàn)“章”的職責。壞名字：utils.py (里面啥都有)
好名字：date_utils.py, string_utils.py
壞函數(shù)：do_stuff()
好函數(shù)：calculate_total_price()2. 避免循環(huán)導入
如果 A 章 import B 章，B 章又 import A 章，Python 會報錯。原因：依賴混亂，職責重疊。
解決：提取公共部分到 C 章，A 和 B 都依賴 C。
使用 TYPE_CHECKING 進行類型提示導入（僅用于靜態(tài)檢查，不實際運行）。3. 配置管理
不要在代碼里寫 db_host = localhost。
建立 config 章：
# config/settings.py
import osclass Settings:DB_HOST = os.getenv('DB_HOST', 'localhost')DB_PORT = int(os.getenv('DB_PORT', 5432))SECRET_KEY = os.getenv('SECRET_KEY', 'dev-key')所有其他章從 config 章讀取配置。
4. 日志規(guī)范
每個章應(yīng)該有獨立的 Logger。
logging.getLogger('db.connector')
這樣在排查問題時，可以單獨開啟 db 章的 DEBUG 日志，而不會淹沒在其他日志里。
七、 總結(jié)與互動
做章，本質(zhì)上是一種工程思維的體現(xiàn)。它強迫你在動手寫代碼前，先思考系統(tǒng)的結(jié)構(gòu)和邊界。
核心回顧：做章 = 模塊化。高內(nèi)聚，低耦合。
源碼解析是手段，目的是理解依賴關(guān)系。
D-R-S-T 流程：拆解、定義、構(gòu)建、測試。
依賴注入是解耦的關(guān)鍵工具。當你掌握了做章，你會發(fā)現(xiàn)，無論是 100 行的腳本，還是 10 萬行的微服務(wù)，底層邏輯是一樣的：分而治之，各司其職。
不要害怕重構(gòu)。剛開始項目小，全寫在一個文件里沒問題。但當文件超過 500 行，或者你開始修改一個地方導致另一個地方報錯時，就是做章的最佳時機。
最后，拋出一個問題引發(fā)討論：
在你們的實際項目中，是傾向于**“先寫完功能再重構(gòu)做章”，還是“先設(shè)計好章節(jié)結(jié)構(gòu)再填代碼”**？
哪種方式讓你踩的坑更少？或者你有沒有遇到過因為“不做章”導致的慘痛教訓？
你更常用哪種寫法？評論區(qū)交流，咱們一起避坑。