只加两行代码，为什么要用两天？

这个需求很简单，怎么实现我不管

“帮我写个电商网站，就淘宝那样的，预算 3000 够不够？不够还可以再加点儿。”

“帮我写个百度那样的搜索引擎，就一个输入框应该花不了多久吧？”

“我这个需求稍微复杂一点，帮我写一个随手机主题颜色而变色的智能后盖，钱不是问题。”

……

不管你是互联网公司的正规军，还是兼职外包的开发者，你或多或少都会遇到各种各样来自产品、客户、老板们的花样繁多的需求，而且他们都一致认为：这个需求很简单。

可事实果真如此吗？

“只加了两行代码，为什么你要用两天时间？”

这种问法看似合理，但背后却隐藏着几种荒谬的思维方式：

• 代码行数 = 工作量

• 代码行数 = 价值

• 代码行之间没有区别，各自对等

很明显，以上三条都是胡说八道。

开发者面对这样的指责，翻白眼之余却也不免委屈，软件开发是把物理世界映射到虚拟世界的一种神奇魔法，回顾我们做出的变更，有太多理由能解释这两行代码为什么要用两天时间。

因为问题报告对于重现方法的描述不够明确。

有时候，我们需要耗费几个小时才能可靠地重现某些问题。遇到这种情况，有些开发人员会立即与问题上报者取得联系，要求对方提供更多详细信息。但也存在一些开发人员讨厌修复 Bug，于是信息不足就成了甩锅的好办法。

因为报告的问题与功能有关，而我对功能不太熟悉。

这里可能涉及某些开发者很少使用的功能，所以对相关细节真的不太熟悉。为此，开发者需要耗费更长的时间理解功能的使用方式，特别是这项功能性 bug 与软件交互的具体流程。

因为我花时间去调查了引发问题的真正原因，而不止流于表面症状。

如果某些代码引发了错误，那直接把它打包在 try…catch 语句中即可有效抑制住错误。没错误，也就没问题了，是吗？当然不是。对有责任心的开发者来说，掩盖问题与解决问题是两码事。掩盖错误很容易引发其他意料之外的副作用。我可不想在未来某个关键时刻再次被同样的错误困扰。

因为除了上报的重现步骤之外，我还调查了其他可能引发同一问题的情况。

一组重现步骤虽然能够轻松让错误再次出现，但往往不足以揭示引发错误的深层次原因。只有找到这种根源性因素，同时研究解决问题的所有可行方法，才算是真正有价值的分析洞见。这可能涉及代码的实际运作方式，可能是其他位置存在其他需要解决的问题，或者是存在某些代码不一致状况（导致某一代码路径中出现错误，其他路径则不会出错）等等。

因为我花时间验证了代码的其余部分是否会受到类似问题的影响。

如果错误源自某项 bug，那么代码库内的其余位置应该也会存在相同的错误。既然有用户上报了，最好是全面检查一下。

因为在发现错误根源时，我希望以最简单的方法加以解决，保证将引入副作用的风险控制在最低水平。

因为我彻底测试了这项变更，并确保其能够解决不同代码路径下的同一问题。

我不想把修复测试这种麻烦事推给其他人。我不希望之后再出现类似的错误，所以我投入了巨大的心力，保证问题得到彻底解决。上下文切换既复杂又枯燥，我希望自己的工作能让专职测试人员再也不用进行本质上“完全相同”的变更。

还有什么比修复 Bug 更烦人的？那就是反复修复同样的 Bug。你只看到了我增加了两行代码，却没看到我在背后分析为什么要加这两行代码，这两行代码为什么要以这种方式实现。

一天就写几行代码，时间都在干嘛？

不少团队的绩效考核指标都曾被爆出过是以“代码行数”为主，部分测试人员则以查杀“Bug”数为依据，各大互联网大厂也都曾把团队动辄千万甚至上亿行代码作为品宣卖点。

这给了外界一个错觉，似乎代码行数成为了一个程序员技术能力、工作产出的万金油式衡量标准。可写得多，就代表写得好吗？那密密麻麻的 if…else 冲击波莫非还能类比成写文章时的排比句式，给人一种气势恢宏之感？

Linus 看了想打人。

事实上，一个程序员的工作产出跟代码行数并不是强相关的，程序员的工作时间也并不仅仅局限在写代码上。

根据国外调研机构 ActiveStates 去年的一份调查报告，包括美国、中国在内的 80 多个国家、上千名开发者样本结果显示：

六成开发者日均编程时间不足 4 小时。

在 1250 份调查样本中，38.8% 的受访者每天只花 2-4 小时编程。这与 2018 年的调查结果相似，37% 的受访者每天花 2-4 小时编程。相比之下，27.92% 的受访者每天花 5-7 小时编程，而 2018 年的调查结果显示，31% 的受访者每天花 5-7 小时编程。

最让人惊讶的是，2019 年总计有多达 61.52% 的受访者花 4 小时甚至更少的时间编程，而在 2018 年，只有 51% 的受访者花 4 小时或更少的时间编程。10.56% 的受访者花 8 小时或更长时间编程，而 2018 年这一比例为 19%，几乎减少了一半。

开发者们花在写代码的时间上越来越少，那么时间都去哪儿了呢？

44% 的受访者表示，他们必须把时间花在各种各样的活动上，包括会议、测试、维护，甚至是社交活动。花费时间最多的单一活动是软件设计 / 架构，占 11.36%，其次是参加 standups/ 会议，占 8.24%。

在中国，这些开发者们可能还需要花费大量的时间在日志、周报的撰写上：

我这几行代码体现了怎样的社会情怀，包含了我哪些精华的技术与商业思考，最大程度地实现了客户价值，满足了用户需求，给团队留下了宝贵的技术财富，为数字化经济的实现添砖加瓦，拉通了团队，对齐了目标，解决了痛点，赋能了行业，复盘了人生。我们程序员真是太厉害啦！

你说，花两天时间是不是还算我效率高了呢？