碎片时间编码与工作量估算

今天是节后开工第一天，总结一下去年自己的编程工作。去年最大的收获是刻意训练了两个能力，一个是碎片时间编码的能力，一个是精确估算工作量的能力。

原来是典型的夜猫子，喜欢大片段的连续时间写代码。写代码的时候往往对时间无感，也没有刻意精确估算过自己的编码耗时。经常是写着一个功能，发现另外一处不好的实现，想着要不顺便重构了，结果连带出许多变更，导致工作量增加，迟迟不能收尾。或者遇到一个大功能，但又懒得做精细化的拆分，想着毕其功于一役，反正大不了熬几宿。

一般也不喜欢在家工作，因为怕被打扰，写代码的时候被人打扰中断会情绪失控。几年前有半年时间待业在家，我都要找个咖啡厅啥的地方呆着写东西，免得在家里和娃们起冲突。

结果去年因为疫情一下子打破了我的这些习惯。最开始在家办公的时候，我为了避免被孩子打扰，昼伏夜出，坚持了半个多月，身体扛不住了，因为白天实际上也休息不好。我开始训练如何降低"中断"导致的上下文切换成本，摸索出几点经验。

首先，在脑子中试运行代码。陪娃听睡前故事的时候，或者是出去遛娃的时候，都可以在脑子里运行代码。代码在脑子里运行过后，大体上消息传递流，方法调用栈，以及抽象封装设计都比较清楚了。

然后，把脑子里的代码抄出来。抄的时候，要按照最小可执行单元来抄，把大目标拆成很多小目标，这样中断后的恢复成本最低。当然这个说起来容易，做起来挺难。很多代码连筋带骨，需要有庖丁解牛的耐心。开始的时候由于很多细节没考虑到，抄出来的时候容易出错，或者被卡住，这时候需要刻意和脑子里的代码对照，思考试运行的时候为啥没想到。反复训练一段时间后，很多错误都可以在脑子里试运行的时候纠正。

最后要严格控制重构冲动，避免完美主义。发现需要重构的地方，顶多写个 TODO 或者记录个 issue，不属于这次小目标的代码不要动，可以接收 workaround 方案。

这样训练一段时间后，差不多可以做到陪娃编码两不误，也不会因为被中断而情绪失控。即便是正常上班后，我自己的工作节奏和作息也完全改变了。基本是早上 8 点到公司，review 下别人的代码以及 github 关注的项目，9 点开始编码，一般到下午 4 点基本就可以收尾，修复代码检查警告啥的，提交代码。5 点前乘路上不堵回家。到家后，提交的代码集成测试也跑完了。辅导娃写作业的期间抽空修复下测试，一天的工作就算完成了。晚上哄娃睡觉时在脑子试运行明天要写的代码，少了熬夜，精神状态也好了许多。

ps: 带个招聘信息，我们需要各种工程师，前后端全栈以及运维。主要要求对区块链以及开源感兴趣，对金融以及 DeFi 感兴趣，技术功底扎实，自驱力强。如果你不懂技术，但有金融产品的设计经验，也可以。简历投至 hr@westar.io (注明来源 jolestar)，或者直接发给我。

原微博中的媒体