无论你是互联网公司的正式员工，还是兼职的外包开发者，几乎都难免会遇到来自产品经理、客户、或老板提出的各种花样繁多的需求。而且，他们往往认为这些需求都“非常简单”。例如：
“帮我做一个电商网站，就像淘宝那样的，预算3000元够不够？不够还可以再加一点。”
“帮我做一个像百度那样的搜索引擎，只是一个输入框而已，应该用不了多久吧？”
“我这个需求稍微复杂一点，做一个可以随手机主题颜色变化的智能后盖，钱不是问题。”
但这些需求真的如此简单吗？
从需求方的角度来看，他们会有类似这样的疑问：“你就加了两行代码，为什么要用两天时间？” 乍一看，这样的提问似乎合情合理，但背后却隐藏着几种错误的思维方式：
代码行数 = 工作量
需求方可能认为，代码的行数直接反映了开发的工作量。但事实远非如此。代码行数 = 价值
他们往往还会觉得，写的代码越多，产出的价值也越大，这也是一个误解。代码之间没有区别，各自对等
需求方可能忽略了不同代码实现的复杂性，认为每行代码的难度是相同的。
显然，这些观点都是不成立的。
作为开发者，当面对这样的质疑时，虽然常常感到无奈，但内心也难免委屈。 回顾我们的工作，我们可以找到很多理由来解释为什么看似“简单”的两行代码实际上需要两天时间。这背后可能涉及复杂的逻辑、系统兼容性问题、测试和调试等诸多因素。
第一，因为问题报告对于重现方法的描述不够明确。
时，我们可能需要花费数个小时才能稳定地重现某些问题。在这种情况下，一些开发人员会立即联系问题的上报者，要求他们提供更多的信息或细节。
第二，因为报告的问题与功能有关，而我对功能不太熟悉。
有时，这可能涉及到一些开发者平时很少接触的功能，因此对相关细节并不熟悉。为了弄清楚这些功能的使用方式，开发者需要花费更多时间去理解，尤其是这个功能性 Bug 与软件交互的具体流程。
第三，因为我花时间去调查了引发问题的真正原因，而不止流于表面症状。
如果某段代码引发了错误，直接将其包裹在 try…catch 语句中就能有效抑制错误了吗？当然不是。对于有责任心的开发者来说，掩盖问题和真正解决问题是完全不同的两回事。简单地掩盖错误可能会导致其他意想不到的副作用，我绝不希望在未来的某个关键时刻再次被同样的错误困扰。
第四，因为除了上报的重现步骤之外，我还调查了其他可能引发同一问题的情况。
一组重现步骤虽然可以轻松让错误再次出现，但往往不足以揭示其深层次原因。只有找出问题的根本原因，并探索解决问题的所有可行方法，才能算是有意义的分析洞见。这可能涉及代码的实际执行方式，可能是在其他地方还有待解决的潜在问题，或者是代码中存在不一致的情况等因素。
第五，因为我花时间验证了代码的其余部分是否会受到类似问题的影响。如果错误源自某项 Bug，那么代码库内的其余位置应该也会存在相同的错误。既然有用户上报了，最好是全面检查一下。
第六，因为在发现错误根源时，我希望以最简单的方法加以解决，保证将引入副作用的风险控制在最低水平。
第七，因为我彻底测试了这项变更，并确保其能够解决不同代码路径下的同一问题。我不想把修复测试这种麻烦事推给其他人。我不希望之后再出现类似的错误，所以我投入了巨大的心力，保证问题得到彻底解决。
一天就写几行代码，其他时间都在干嘛？
不少团队的绩效考核曾被曝以“代码行数”为主要指标，部分测试人员则以发现“Bug”的数量作为衡量标准。很多大型互联网公司也将动辄数千万甚至上亿行的代码量作为宣传的亮点。这给外界造成了一种错觉，仿佛代码行数成为评判程序员技术能力和工作产出的通用标准。但写得多，真的就代表写得好吗？
实际上，程序员的工作产出与代码行数并没有直接关联，而且他们的工作内容也不只是写代码而已。根据国外调研机构 ActiveState 去年的一份调查报告，涵盖美国、中国等80多个国家的上千名开发者数据显示：约60%的开发者每天编程时间不足4小时。在1250个调查样本中，38.8%的受访者每天只花2-4小时编程。与2018年的调查数据相似，27.92%的受访者每天编程5-7小时，而2018年这一比例为31%。此外，只有10.56%的受访者每天编程8小时或更长，较2018年的19%几乎减半。
那么，开发者们的时间都花在哪儿了？44%的受访者表示，他们的时间被分散在各种活动中，如会议、测试、维护，甚至社交活动。其中，花费时间最多的单项活动是软件设计和架构，占11.36%。在中国，开发者可能还要花费大量时间撰写日志、周报。所以，如果一项工作需要两天时间，效率算高吗？对此，你怎么看？