别在 Python 课上照本宣科，试试这样搞项目 周末刚好有个老同学来找，问我要教他如何写个“自动抓取股票走势图”的小工具。他看着代码堂，一脸懵逼。我直接开了个会，让他重写一遍：“行吧，别拿老一套，今天咱们不整那些教科书味儿。” 结局他刚敲下第一行 `import requests`，立马认定自己是资深开发者。我打断他：“先别急着装大佬。
你看这个 `requests` 库，它到底干了啥？就是往外扔数据。
那代码写得再花哨，要是它不懂如何从互联网上去拿东西，那它就是个哑巴。” 别总想着“封装” 目前大量人一上来就想封装函数，把逻辑藏起来。我认定这就像你煮饭，非要把自己拆成零件放在冰箱里，结局煮饭的时候还得自己剥壳、洗菜、切菜，最终还得重新组装。 真正的高手，是把灶台间变成战场，而不是把它变成了仓库。 实战时刻 那天下午，我让他直接动手写个脚本，不加点装饰，不写注释，就干巴巴地跑通。他一启动想写个类，结局发现类是为了封装方式的，不是为了藏方式的。 他写了一个 `fetch_data` 函数，参数是 `url` 和 `header`，回是 `json`。
然后他又写了 `get_stock_data`，封装了 `fetch_data` 的逻辑。 我又指着屏幕说：“看，这就是类。类的职责只有一个：管理数据。它不能与此同时负责‘去官网拿数据’和‘处理数据’。
要是它想处理数据，就得把 `fetch_data` 拆出去，变成另一个模块要么函数。否则，当你想改 URL 要么改脑袋的 API Key 的时候，你得翻遍整个类定义，找哪个方式对应哪个动作，这一找，导师都得被问爆。” 我让他把 `headers` 参数独立成一个小函数，就连直接定义为字典。 “工具不要当武器。”我说，“别把自己包装成不可复制的神。对外供给接口，对内负责脏活累活。” 数据是精神食粮，别只当工具 刚刚那个例子，最让我头疼的是数据。代码里全是 `requests.get(url, kwargs)` 这种大杂烩。 “再改改，把 `headers` 放进去。”我喊道，“还要加 `timeout`，还要处理 `json` 解析异常。
要是这三个参数都需求传，你的函数参数列表会变得像个 N 维坐标。你当作你在写函数，实际上你是在写配置项。 真相是：
1. 接口忒碎：你拿不到整个的用例。
2. 调试地狱：要是我今天改个 HTTP 头，明天改个超时工夫，你得多写几行注释去对应。
3. 维护成本：赶明儿想加个新浪的账号，你得找那个 `headers` 字段，还得找那个 `timeout` 字段。两个地方都得改，万一漏了，数据就全丢。 “别让你的 API 文档只存有于你的脑壳里。” 我让他把那些不同的请求头、不同的超时设置，单独拆成一个个参数，就连用 `config` 字典来管理。 ```python import requests import json def fetch_stock_info(config): config 里包含了 url, headers, timeout 等 别让它忒复杂，也别让它忒乱 response = requests.get(config['url'], headers=config['headers'], timeout=config['timeout']) return response.json() ``` 你看，目前要是我想换数据源，是不是只需求改 `stock_info` 函数里的 `config` 参数？彻底不需求动代码逻辑，也不需求重绘了。 实战避坑指南：别造反 写代码的时候，我让他尝试搞个 `main` 函数。他写了一堆 `if` 和 `else`，把不同的数据源都塞进去了。 “这像不像一个庞大的 `switch-case` 嵌套得忒深了？”我问。 他嘿嘿一笑：“别看看起来像，但我想改条款还得换个地方。” 我拿出一个真的例子，告诉他：“别去造反，要收敛。真正的工程化项目，是模块化的。” 他最终写了一个 `Project` 类，里面藏了 `Config`, `Parser`, `Logger` 这些模块。他说：“这样看起来结构凑合，像个金字塔。” 我皱眉：“别当作多了就稳了。
要是 `Config` 类忒臃肿，它就应当拆分成 `BaseConfig` 和 `SpecificConfig`。
要是 `Parser` 想处理 `CSV` 或 `JSON`，它就该拆成 `CSVLoader` 和 `JSONLoader`。 记住，程序的结构，就是它用来解释难题的方式。 尾声：让代码帮你干活 项目终止之前，我让他把 `fetch_stock_info` 里的逻辑取出来，变成独立的函数，就连做成 `HttpClient` 这个基类。 “目前，”我指着他的代码，“你写函数的时候，脑子里在想啥？你在想‘我要去官网拿数据’吗？你在想‘我要解析 JSON'吗？还是你在想‘我要处理异常’？” 说实话，他在那边愣了一下。 “别总想着‘起初、其次、最终’写东西。写代码的时候，你的思维应当是：‘我要做啥动作’，而不是‘我要按照啥步骤做完这件事’。” 他说：“懂了。
那我赶明儿写函数，只想告诉它‘给我个 URL'，它自己拍板如何去。” 我点点头：“对。
不要对变量下定义。 把状态管理放到全局配置要么配置项里去，别在函数里用 `local_var` 到处乱搞。变量就是记忆，不是临时变量。 最终，他问我：“老师，那要是我想加个 `auto_dim` 参数呢？” “好办。你去看看那会儿的代码，看那个 `SpecificConfig` 里有没有 `auto_dim` 字段。
没有，就新建一个，要么改个默认值，然后直接放进 `config` 字典里。别去造新的类，也别去改现有类的结构，直接给参数加点料。 这就是职业开发，别把自己当成程序员，你得是项目经理，是架构师，是能把想法落地的人。 代码不是用来炫技的，它是用来帮你干活、帮你省事儿、帮你躲开那些坑的。别让它忒复杂，别让它忒晦涩。 希望下次上课，你能少见怪，多改观。
毕竟，最好的代码，是那些看不见的、宁静地运行在背后的东西。” （注：本案例基于真开发场景模拟，旨在探讨代码结构优化与工程化思维，非教科书式教学。）