我见过最离谱的网站脚本网站脚本，是网站脚本某个电商后台的库存检查。那脚本凌晨三点准时跑，网站脚本把数据库里所有“已售罄”的网站脚本商品挨个翻出来，给运营发邮件。网站脚本问题是网站脚本，它发的网站脚本不是提醒邮件，是网站脚本那种“您的商品已售罄，请及时补货”的网站脚本自动回复，收件人却是网站脚本顾客。运营第二天上班，网站脚本邮箱里塞了四百多封退单申请。网站脚本
写脚本的网站脚本人早就离职了，注释写得像天书，网站脚本没人敢动那玩意儿。网站脚本后来新来的实习生看了一眼，说这不就是个if判断写反了嘛。改一行代码，世界清净了。
这事儿让我想起另一个极端——有个朋友做数据抓取，脚本写得跟艺术品似的，每个函数都有docstring，异常处理细分到网络超时和DNS解析失败都分开写。结果呢？对方网站改了个CSS类名，他的脚本直接崩溃。他花了三天排查，最后发现是选择器没匹配上。你说这是脚本的问题吗？不，是这个世界变化太快，而脚本总是滞后。
脚本这东西，本质上是把人类对“重复劳动”的厌恶，翻译成机器能听懂的逻辑。但麻烦在于，人类对“什么算重复”的定义，经常和现实脱节。我见过有人写脚本自动整理桌面文件，按扩展名分类，结果把系统自带的快捷方式全挪走了，开机直接黑屏。也见过有人写脚本自动回复工作消息，关键词匹配“好的”“收到”，结果领导发来“这个方案再改改”，脚本回了句“好的，收到”，领导沉默了半小时。
最讽刺的是，脚本本身往往比写脚本的人活得久。你入职时接手一个老系统，里面几十个脚本在跑，没人说得清每个是干嘛的。你不敢停，怕停了出事儿；你也不敢改，怕改出更大的事儿。就这么耗着，直到某天服务器宕机，运维重启后发现所有脚本都不见了——原来它们存在临时目录里，重启就清空。那一刻，所有人都松了口气。
我自己的经验是，脚本越短越好，最好短到一眼能看完。别整那些花里胡哨的框架，也别追求什么设计模式。一个跑批任务，用shell写三行搞定，就别上Python。用Python写十行搞定，就别上Java。复杂化不是本事，简单才是。当然，这道理我花了五年才想明白，期间写过无数个自己都看不懂的长篇脚本。
前几天我清理旧项目，发现一个五年前写的定时备份脚本。打开一看，里面有个变量叫temp_flag，赋值true，然后整个if块是空的，注释写着“暂时用不到，先留着”。我盯着那行代码看了半天，愣是没想起来当时为什么留这么个东西。删了，跑了一遍，一切正常。
这就是脚本的宿命——你写它的时候觉得逻辑清晰，过半年再看，跟看别人写的没什么两样。它要么在暗处默默干活，要么在某个凌晨三点突然爆炸，把所有人都吵醒。