极客视点
极客时间编辑部
极客时间编辑部
113245 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:22
登录|注册

只加两行代码,为什么要用两天?

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

一天就写几行代码,其他时间都在干嘛?

不少团队的绩效考核指标都曾被爆出过是以“代码行数”为主,部分测试人员则以查杀“Bug”数为依据,各大互联网大厂也都曾把团队动辄千万甚至上亿行代码作为品宣卖点。
这给了外界一个错觉,似乎代码行数成为了一个程序员技术能力、工作产出的万金油式衡量标准。可写得多,就代表写得好吗?
事实上,一个程序员的工作产出跟代码行数并不是强相关的,程序员的工作时间也并不仅仅局限在写代码上。
根据国外调研机构 ActiveStates 去年的一份调查报告,包括美国、中国在内的 80 多个国家、上千名开发者样本结果显示:六成开发者日均编程时间不足 4 小时。
在 1250 份调查样本中,38.8% 的受访者每天只花 2-4 小时编程。这与 2018 年的调查结果相似。相比之下,27.92% 的受访者每天花 5-7 小时编程,而 2018 年的调查结果显示,31% 的受访者每天花 5-7 小时编程。另外,10.56% 的受访者花 8 小时或更长时间编程,而 2018 年这一比例为 19%,几乎减少了一半。
开发者们花在写代码的时间上越来越少,那么时间都去哪儿了呢?
44% 的受访者表示,他们必须把时间花在各种各样的活动上,包括会议、测试、维护,甚至是社交活动。花费时间最多的单一活动是软件设计 / 架构,占 11.36%。
在中国,这些开发者们可能还需要花费大量的时间在日志、周报的撰写上,所以,花两天时间,效率是不是还算高呢?
对于以上问题,你怎么看?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(3)

  • 最新
  • 精选
  • Monday
    一位富翁腿骨折,医生用一根镙丝钉将骨头接好了收50000元。富翁很不高兴并写了一封信给医生,要求列出收费明细。 医生在账单写到: 1根镙丝钉:1元。 怎样放进去:49999元。 富翁看了沉默了,没有再说什么。 我们的两行代码不就是那颗螺丝钉吗?
    1
    9
  • lipsum
    感觉一天只有两个小时在编程,其他都在想逻辑,处理杂事😂😂😂
    2
  • 漂泊的小飘
    所以技术合伙人还是很有必要的
收起评论
显示
设置
留言
3
收藏
33
沉浸
阅读
分享
手机端
快捷键
回顶部