30天9个项目，Python老手被新手项目打脸了

去年Stack Overflow的开发者调查显示，Python连续第6年成为最想学习的语言。但有个数据被忽略了——67%的受访者在"实际写过多少行生产代码"这道题上选了不到1000行。

想学的人多，动手的人少，这是第一道坎。

作者Pranjal Saxena的实验很直接：30天，9个从零开始的项目，每天2-4小时。他不是新手，有5年Python经验，在AWS做解决方案架构师。但实验结果让他重新理解了"会用"和"能用"的区别。

第1-10天：被"简单项目"教做人

前三个项目看起来像是编程101的作业：石头剪刀布、计算器、猜数字游戏。Saxena在博客里写得很坦诚——「我低估了这些项目。以为两小时搞定，结果每个都花了将近一天。」

问题出在边界情况。石头剪刀布的输入验证、计算器的浮点精度、猜数字的异常处理，这些"不重要"的细节占用了80%的时间。生产代码和教程代码的区别，就是有没有处理用户会怎么搞砸。

第四个项目是井字棋。这里他开始引入Minimax算法，让AI变得不可战胜。代码量从50行膨胀到200行，但核心收获是理解了递归在实际场景中的代价——深度优先搜索在3x3棋盘上没问题，放到围棋上就是灾难。

第五个项目是语言检测器，用到了NLTK库。这是他第一次接触自然语言处理，准确率只有73%，但让他意识到数据预处理比模型选择更重要。「清洗数据的时间占了70%，」他在复盘里写，「这和我在AWS看到的客户案例一模一样。」

第11-20天：被迫面对自己逃避的东西

第六个项目是网络爬虫，抓取电商网站的价格。Saxena之前一直回避爬虫，因为涉及法律灰色地带和反爬机制。这次他花了整整三天研究robots.txt、请求频率控制、User-Agent轮换。

「合法地爬数据比写爬虫代码难十倍，」他记录道。技术问题的解法往往在技术之外。

第七个项目是数据库管理系统，用SQLite做后端。这里他踩了ORM的坑——SQLAlchemy的自动提交机制在并发场景下的表现，和文档描述不完全一致。他最终回退到原始SQL，但保留了ORM的模型定义层。这种"混合架构"是他之前不会考虑的妥协。

第八个项目是实时聊天应用，用Flask-SocketIO实现。WebSocket的连接状态管理让他头疼了很久：断线重连、消息顺序保证、心跳检测。这些在HTTP时代被隐藏的问题，全暴露了出来。

第21-30天：最意外的收获来自最丑的代码

第九个项目是个人财务追踪器，也是最后一个。功能最简单：记录收支、生成报表、数据可视化。但Saxena说这是30天里学到最多的项目。

原因很尴尬：他赶时间，代码写得极烂。没有单元测试，硬编码配置，视图和逻辑耦合。两周后他自己都看不懂了，被迫重构。「这是我第一次真正理解为什么要写'能删的代码'，」他写道，「不是为未来维护，是为两周后的自己。」

30天结束后的统计：9个项目，总代码量约4000行，删除重写的比例接近60%。GitHub仓库收获了2300个star，但Saxena说这个数字和实际收获无关。

他在总结里列了三个反直觉的发现：

第一，项目难度和收获不成正比。石头剪刀布教会他的输入验证思维，比聊天应用的WebSocket知识更常用。

第二，完成比完美重要，但"完成"的定义需要重新谈判。他的标准是"能给别人用"，而不是"能跑通"。

第三，文档阅读能力比Stack Overflow搜索能力提升更快。后期他解决问题的时间中，读官方文档的比例从20%上升到70%。

给想复制这个实验的人

Saxena没有给出项目清单的链接，但描述了选择标准：每个项目必须解决一个他"大概知道怎么做，但从来没做过"的问题。不是完全陌生的领域（比如深度学习），也不是熟练到能闭着眼写的功能。

时间分配上，他建议把30%留给"让代码能跑"，70%留给"让代码能活"——错误处理、日志、配置管理、部署文档。这些在教程里被跳过的东西，决定了项目能不能在一个月后还被用起来。

最后他提到一个细节：第15天的时候他想放弃，因为聊天应用的bug怎么也修不好。那天他去了趟健身房，回来继续。后来他在每个项目里都安排了强制中断，「大脑需要后台进程来处理阻塞的问题。」

实验结束后，Saxena把9个项目部署到了AWS免费层，作为技术面试时的演示素材。有面试官问他：「如果重做这30天，你会怎么安排？」

他的回答是：「第0天先写一个测试框架。不是因为我后来写了测试，是因为我发现自己一直在重复造同一个轮子。」

你现在电脑上有没有一个文件夹，名字叫"learn-python"或者类似的东西，创建时间是六个月前，里面只有一个hello.py？