还记得【Python项目实战】项目·命令行待办清单：文件读写 + JSON持久化 这一篇文章我说“为什么不分utils/？故意的”吗？今天就来收网。把你亲手写的待办清单v1拆开重装——功能一行不变，结构脱胎换骨。这一课叫重构，是初级和进阶的分水岭。🎯本篇成品：待办清单v2——模块化、异常体系、logging上岗。功能不变，但代码从“能跑”变成了“能维护”。📌 太长不看版（给想快速上手的你）项目信息一句话说明重构对象待办清单v1（~120行单文件）重构后结构main.py+utils/storage.py+utils/service.py功能变化一行不变（验收清单全部通过）解决了什么5个“坏味道”：职责混杂、print与逻辑缠绕、错误处理散落、路径不锚定、没有日志核心知识点模块化拆分、自定义异常、logging上岗、路径锚定做完你能得到一套“敢动、能改、可测试”的项目代码💡 顺便说一个工作真相：程序员的日常里，80%的时间在读旧代码、改旧代码，写新代码反而是少数。重构，就是和旧代码打交道的手艺。一、什么是重构：先立三条军规重构 =不改变功能，只改善内部结构。“功能不变”不是口号，是验收标准。开工前先立三条纪律，全程遵守：军规说明为什么要这样① 行为不变是底线改完之后，验收清单必须原样全过这叫回归验证——没验证的重构等于没做② 一次只动一处拆完storage验证一次，再拆service大爆炸式重写是项目死亡的头号原因③ 每一步都commitGit是重构的安全网改崩了？git diff看改了啥，git restore回退。这就是你第4篇学add/commit的真正原因二、代码考古：给v1挑五个毛病（坏味道清单）把第7篇的main.py打开，咱们用挑剔的眼光重新看它：#v1的坏味道症状后果①三种职责挤一个文件数据读写、业务逻辑、界面输出互相纠缠改一处怕碰坏另一处，不敢动②业务函数边算边打印add_todo里既改数据又print结果没法被别的代码复用，也没法测试③try/except + print散落各处报错样式不统一，改提示要改四遍错误处理没有“户口”④数据文件跟着运行目录跑换个文件夹启动，数据“凭空消失”隐蔽bug，用户替你的代码背锅⑤出了问题无从查起只有print，没有运行轨迹用户说“它不对劲”，你两眼一抹黑💡考古不是否定过去的自己——v1的每个决定在当时都合理；只是项目长大、要求变高后，结构必须跟上。这就是重构的正当性。三、手术方案：从1个文件到3个角色v1（单文件混沌） v2（模块化清晰） todo_project/ todo_project/ └── main.py（什么都干） ├── main.py # 🚪 入口：解析参数、统一输出 ├── utils/ │ ├── __init__.py │ ├── storage.py # 📦 数据读写（只管数据） │ └── service.py # ⚙️ 业务逻辑（只管业务） ├── todos.json └── todo.log # 📋 新朋友：运行日志🏪 三个角色的分工像一家小店角色文件职责比喻前台main.py接待、传话、展示结果点单/上菜大厨service.py业务逻辑（增删改查）做菜库房storage.py数据读写（JSON进出）进货出货🎯第5篇的项目结构模板，今天第一次真的用上。四、手术1：拆出storage.py（顺手修一个隐藏bug）"""storage —— 待办数据的读与写（只管数据，不管业务）"""importjsonimportloggingfrompathlibimportPath logger=logging.getLogger(__name__)# 🔑 锚定到项目根目录：不管从哪儿启动程序，数据都在同一个地方DATA_FILE=Path(__file__).resolve().parent.parent/"todos.json"defload_todos()-list:"""读数据；文件不存在（第一次用）返回空列表"""ifnotDATA_FILE.exists():logger.info("数据文件不存在，返回空清单")return[]todos=json.loads(DATA_FILE.read_text(encoding="utf-8"))logger.info("读取待办 %d 条",len(todos))returntodosdefsave_todos(todos:list)-None:text