江苏龙网

  1. 首页 > 资讯 > 科技 > >

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


InfoQ|只加两行代码，为什么要用两天？
本文插图

作者 | 小智、核子可乐
1 这个需求很简单 ， 怎么实现我不管
“帮我写个电商网站 ， 就淘宝那样的 ， 预算 3000 够不够？不够还可以再加点儿 。 ”
“帮我写个百度那样的搜索引擎 ， 就一个输入框应该花不了多久吧？”
“我这个需求稍微复杂一点 ， 帮我写一个随手机主题颜色而变色的智能后盖 ， 钱不是问题 。 ”
……
不管你是互联网公司的正规军 ， 还是兼职外包的开发者 ， 你或多或少都会遇到各种各样来自产品、客户、老板们的花样繁多的需求 ， 而且他们都一致认为：这个需求很简单 。
可事实果真如此吗？
“只加了两行代码 ， 为什么你要用两天时间？”
这种问法看似合理 ， 但背后却隐藏着几种荒谬的思维方式：
代码行数 = 工作量
代码行数 = 价值
代码行之间没有区别 ， 各自对等
很明显 ， 以上三条都是胡说八道 。
开发者面对这样的指责 ， 翻白眼之余却也不免委屈 ， 软件开发是把物理世界映射到虚拟世界的一种神奇魔法 ， 回顾我们做出的变更 ， 有太多理由能解释这两行代码为什么要用两天时间 。
因为问题报告对于重现方法的描述不够明确 。
有时候 ， 我们需要耗费几个小时才能可靠地重现某些问题 。 遇到这种情况 ， 有些开发人员会立即与问题上报者取得联系 ， 要求对方提供更多详细信息 。 但也存在一些开发人员讨厌修复 Bug ， 于是信息不足就成了甩锅的好办法 。
因为报告的问题与功能有关 ， 而我对功能不太熟悉 。
这里可能涉及某些开发者很少使用的功能 ， 所以对相关细节真的不太熟悉 。 为此 ， 开发者需要耗费更长的时间理解功能的使用方式 ， 特别是这项功能性 bug 与软件交互的具体流程 。
因为我花时间去调查了引发问题的真正原因 ， 而不止流于表面症状 。
如果某些代码引发了错误 ， 那直接把它打包在 try..catch 语句中即可有效抑制住错误 。 没错误 ， 也就没问题了 ， 是吗？当然不是 。 对有责任心的开发者来说 ， 掩盖问题与解决问题是两码事 。 掩盖错误很容易引发其他意料之外的副作用 。 我可不想在未来某个关键时刻再次被同样的错误困扰 。
因为除了上报的重现步骤之外 ， 我还调查了其他可能引发同一问题的情况 。
一组重现步骤虽然能够轻松让错误再次出现 ， 但往往不足以揭示引发错误的深层次原因 。 只有找到这种根源性因素 ， 同时研究解决问题的所有可行方法 ， 才算是真正有价值的分析洞见 。 这可能涉及代码的实际运作方式 ， 可能是其他位置存在其他需要解决的问题 ， 或者是存在某些代码不一致状况（导致某一代码路径中出现错误 ， 其他路径则不会出错）等等 。
因为我花时间验证了代码的其余部分是否会受到类似问题的影响 。
如果错误源自某项 bug ， 那么代码库内的其余位置应该也会存在相同的错误 。 既然有用户上报了 ， 最好是全面检查一下 。
因为在发现错误根源时 ， 我希望以最简单的方法加以解决 ， 保证将引入副作用的风险控制在最低水平 。
因为我彻底测试了这项变更 ， 并确保其能够解决不同代码路径下的同一问题 。
我不想把修复测试这种麻烦事推给其他人 。 我不希望之后再出现类似的错误 ， 所以我投入了巨大的心力 ， 保证问题得到彻底解决 。 上下文切换既复杂又枯燥 ， 我希望自己的工作能让专职测试人员再也不用进行本质上“完全相同”的变更 。
还有什么比修复 Bug 更烦人的？那就是反复修复同样的 Bug 。 你只看到了我增加了两行代码 ， 却没看到我在背后分析为什么要加这两行代码 ， 这两行代码为什么要以这种方式实现 。
2 一天就写几行代码 ， 时间都在干嘛？


推荐阅读


上一篇：宅秘|荣耀亲选智能恒温电热水壶首发 可除水中异味售169元

下一篇：新京报|美国秀出“5G干净网络”名单，但有个“网络”它绝不敢公开