A一条命令收掉手工流程
把每周都要重复十几次的对账与巡检步骤,压进一个能自己跑完的脚本里。目标很具体:任何一次执行,从敲下回车到出结果不超过两分钟,且失败时能指出是哪一行数据不对劲。
白天写代码,晚上写字,中间隔着一杯忘掉的茶。这个域名是我自己的地方: 不放教程,不带节奏,不追热点,只留下我在某个阶段真正想清楚、并且愿意署名的东西。
一段不太长的自我介绍
我做了十多年的软件,写过后台系统、爬虫队列、支付对账,也修过凌晨三点炸掉的定时任务。 这些年下来,我对「工具」这件事的看法变得很朴素:能少一步就少一步,能看懂的就别封装。 所以我的代码通常不花哨,注释比同事写的多一点,出错时日志能自己把话说清楚。
工作之外,我的时间大致分成三份:跑步、读旧书、以及把想不明白的问题写成文字。 跑步是为了让脑子安静下来,读书是为了不让自己太快变得笃定, 写字是因为——只有写出来的时候,我才知道自己到底有没有想清楚。
我不太擅长社交,但很愿意为认真的提问花上一整个下午。如果我们在同一个问题上卡过, 邮件往往是最好的开场。
截至这个秋天,持续在推进的几件小事
把每周都要重复十几次的对账与巡检步骤,压进一个能自己跑完的脚本里。目标很具体:任何一次执行,从敲下回车到出结果不超过两分钟,且失败时能指出是哪一行数据不对劲。
《人月神话》第三遍,这次带着真实项目去读,感受和十年前完全不同。《数据密集型应用系统设计》当作字典用,每次遇到取舍问题就翻对应那一章,比看任何新文章都管用。
停了半年,体感退化得很诚实。现在按周计划慢慢加量,每周三和周六在湘江边跑,配速不追,先追规律。跑步这件事教会我的东西,和写代码用的是同一套逻辑:别指望临场爆发,只能靠日常积累。
一个跑了四年、没人敢动的服务,正在一点点补上回归测试。不重构、不改架构,只是给它织一张安全网。补到能安心改动的程度,就算这一阶段完成。
零散的经验,按时间从近到远
用得久、换不掉的几样
我不迷信工具,但确实有几样东西用了很多年,已经变成手的延伸。 选它们的理由都很简单:启动快、行为可预测、出问题时我能自己查明白。 编辑器我会尽量少装插件,终端永远留着几个自己写的小脚本。
不设留言板,邮件就够了
我不做社群,也没有群二维码。想聊技术问题、指出某篇笔记里的错误、 或者只是想说说你在类似场景里的做法,直接写信给我都可以。 我读得慢,但一般都会回——尤其是那种把背景交代清楚、问得很具体的信。
如果是提问,请附上你的环境、你期望的结果、以及你已经试过的办法。 这三样东西齐全,回复会快很多。