程序员的"时间膨胀"现象
如果你问我，程序员最神奇的超能力是什么，我会毫不犹豫地告诉你——时间扭曲。
懂的都懂
某天下午4点，产品经理说："小王，这个功能很简单，改个bug就行，半小时应该够了吧？"
我自信地点头："没问题！"
然后，我打开代码，开始看。一看，发现问题没那么简单。这个bug背后还有三个bug，三个bug后面还有七个历史遗留问题。
再抬头一看——晚上8点了。
"半小时"去哪了？
时间膨胀的几种形式
形式一：修bug式膨胀
预计：10分钟
实际：3小时
理由："我只是在找bug，bug找着找着就变成了重构。"
形式二：部署式膨胀
预计：15分钟
实际：2小时
理由："部署脚本明明昨天跑得好好的啊！"
形式三：会议式膨胀
预计：30分钟
实际：2.5小时
理由："就简单碰一下" = "从架构设计聊到隔壁公司的咖啡"
老板的时间 vs 我的时间
老板：改个按钮颜色，2分钟够吧？
我：10分钟改完，然后花2小时测试、30分钟写文档、1小时和前端对齐……
老板：你为什么用了一下午？
我：我……我也不知道。
时间去哪了？
我研究了很多年，总结出几个定律：
定律一：墨菲定律的变体
如果一个问题看起来很简单，那它一定不简单。
定律二：连锁反应定律
改一行代码，会触发三个隐藏bug、两个格式问题和一个配置冲突。
定律三：调试定律
你以为问题在A，花半天时间调试后发现，真正的问题在B，而且B是之前A导致的。
定律四："就改一点点"定律
"就改一点点" = "顺便把相关代码重构一下、优化一下、完善一下文档……"
我的时间膨胀故事
有一次，运维说："服务器CPU有点高，你看看什么情况。"
我想：简单，查一下进程就行。
结果：
- 10分钟：查出是某个接口占用高
- 30分钟：发现这个接口的代码很复杂
- 1小时：决定优化一下代码
- 2小时：发现优化会影响到其他模块
- 3小时：决定把相关模块一起重构
- 5小时：重构完了，测试发现新问题
- 晚上8点：终于搞定了
运维："你效率很高啊，一下午就搞定了。"
我："……"（不敢说话）
给同事的建议
给产品经理：
- 听到"很简单"时，心里打个折
- 问问"简单到什么程度"，如果回答"就是改个按钮"，那就预留3天
给运维：
- 不要在周五下班前说"简单看一下"
- 不要说"应该不难"，那意味着"很难"
给程序员自己：
- 别再说"很快就好"，说"我需要评估一下"
- 留出50%的buffer时间
- 学会"时间膨胀管理"：预计2小时，就说4小时
最后的思考
其实，时间膨胀不是bug，是feature。
为什么？因为：
- 我们追求完美，所以花时间优化
- 我们负责到底，所以花时间测试
- 我们重视质量，所以花时间重构
这些"膨胀"的时间，让我们产出了更好的代码。
只是……下次老板问要多久时，我还是会："很快就好！"
毕竟，乐观是程序员的另一个超能力。
（然后晚上又加班）
