上周帮朋友改一段 Python 脚本，他把 200 行逻辑全塞进一个函数里，变量名全是 a1、b2、tmp，调试时连他自己都得翻三遍才找到 bug 在哪。后来我们一块儿拆逻辑、加注释、分函数，不到一小时就跑通了——不是技术多高，是思路理顺了。
别急着敲回车，先问自己三个问题
写代码前花两分钟想清楚，比写完再返工强十倍：
1. 这段逻辑到底在解决什么真实问题？
比如做个小工具批量重命名照片，别一上来就写 os.listdir()，先想：照片按什么规则改？有没有例外（比如封面图不能动）？用户会不会误删？想明白这些，函数边界和异常处理自然就出来了。
2. 数据从哪来，到哪去，中间怎么变？
画个草图就行：输入是文件列表 → 过滤掉非 JPG → 按拍摄时间排序 → 加上前缀再重命名。每一步都是独立的小任务，对应一个函数或方法，而不是 all-in-one 的大杂烩。
3. 如果明天我完全不记得这事，能靠代码本身看懂吗？
变量名用 photo_files 不用 list1；函数名写 get_sorted_jpgs() 别写 func_a()；关键判断加一句注释，比如：
# 跳过隐藏文件（macOS 的 .DS_Store 或 Linux 的 .thumb）几个常用思想，用得顺手就成习惯
单一职责：一个函数只干一件事。哪怕只是提取文件名后缀，也值得单独拎出来：
def get_extension(filename):
return filename.split('.')[-1].lower()以后要支持带多个点的文件名（如 archive.tar.gz），只改这一处，不影响其他逻辑。
面向变化编程：把容易变的部分抽出来。比如导出 Excel 的路径，别硬编码：
OUTPUT_DIR = "./exports" # 改这里，不用动所有 open() 调用防御式写法：别假设输入一定靠谱。读配置文件前先检查是否存在，调 API 前先判空，连字符串分割都加个 if "." in filename: 再 split。
我的随手记法：一页纸笔记模板
现在我写新功能，习惯先撕张纸，分四栏：
- 目标：一句话说清“这东西到底让电脑替我做什么”
- 输入：用户给什么？文件？按钮点击？API 返回的 JSON？
- 关键步骤：最多列 4 步，像做菜写“焯水→炒香→加料→收汁”
- 坑点提醒：比如“注意 Windows 路径反斜杠”、“Excel 单元格长度超 32767 会截断”
写完拍张照存手机，代码写一半卡住了，翻出来瞄一眼，往往就接上了。
编程思想不是玄学，是省时间的工具。你写的每一行代码，背后都有人曾踩过的坑、试过的路。把这些想清楚、记下来、常翻翻，比背一百个语法糖实在得多。