Medium上有个现象：Python教程每天更新，3.5M月活读者追着看，但评论区永远有人在问——"为什么我的代码一超过300行就开始腐烂？"
这不是能力问题，是结构能力的缺失。而市面上几乎没人教这个。
「精通Python」的幻觉是怎么来的
Huzair Awan在文章里描述了一种典型路径：Google报错→Stack Overflow复制→跑通就删书签。循环往复，直到某天发现——
修一个bug冒出三个新bug。改一行代码要测两小时。自己写的模块，三个月后不敢碰。
这时候大多数人会自我怀疑：是不是Python还没学透？再去刷一遍LeetCode，再学几个装饰器语法糖。
Awan的观察很毒：「他们能比解释题目更快地解出LeetCode，但真实项目代码一团糟。」
问题被误判了。语法熟练度和工程能力是两回事，就像会砌砖不等于会盖楼。
代码腐烂的临界点：为什么是300行
有个未经宣之于口但反复出现的数字：几百行。
Awan写道，「项目跨过几百行后，一切开始崩塌。」这不是巧合。人类工作记忆的容量大概在4个独立概念左右，而一段未经拆分的代码，几百行里可能藏着十几个隐式依赖。
这时候你面对的不是代码，是一团缠绕的 Christmas lights——扯一下这里，那边暗了。
Python的简洁语法反而成了陷阱。它让你以为「写出来能跑」等于「写对了」。Java或C++的样板代码至少强迫你提前想结构，Python的放任则把结构问题推迟到还债那天。
所谓「Pythonic」，从来不是代码短，是意图清晰。
结构能力到底是什么
Awan没展开讲，但从他的描述里能拼凑出轮廓：模块边界、依赖方向、变化隔离。
简单说，就是「拆」的能力——把大问题拆成小问题，把大问题拆成稳定接口，把变化频繁的部分和稳定的部分隔开。
这听起来像软件工程的老生常谈，但Python生态有个特殊困境：教程市场极度饱和，工程教育极度稀缺。Medium上每天有无数「10个让你代码更Pythonic的技巧」，但「如何设计一个能活过6个月的模块」没人写。
因为后者不好写。它需要案例，需要失败复盘，需要承认「我当初搞砸了」。
而算法题有标准答案，结构题没有。你没法通过刷题获得肌肉记忆，只能在真实项目的废墟里长记性。
一个可能的出路
Awan的文章停在付费墙前，但标题本身已经是个诊断：You're Not Bad at Python — You're Bad at Structuring Code。
这句话的潜台词是，结构能力是可习得的，只是路径和学语法不同。
具体怎么做？他没说。但结合Python社区的实践，有几个方向值得试：强制自己写模块级文档，不是注释，是「这个文件不依赖谁、不被谁依赖」的契约；用类型提示暴露接口，让隐式依赖显式化；定期做「删除测试」——删掉一个模块，看多少地方报错。
这些都不性感，不像新语法那样能发朋友圈。但代码活得久的产品，背后都是这种脏活。
最后留个数据点：Awan的账号标签里写着Cybersecurity、Developer、Tech Writer、Researcher、Learner——五个身份，Learner放在最后。或许这才是结构能力的起点：承认自己还在学，而不是已经「精通」了什么。
你的代码库里，最老的一个模块活了多久？上一次你敢于大规模重构它，是什么时候？
热门跟贴