程序员最常见的谎话和我自己的理解

大部分答案是以下内容的变种:

  • 这个任务简单;[给出具体计划,永远不要就简单和复杂做出评价,这是主观的
  • 我就快做完了;[具体还有哪些要做,哪些没做,永远不要模糊回答
  • 如果有 Bug,绝不可能是在我的代码中;[只需要接受事实
  • 下个版本中我就会加上单元测试;[如果需要加,就现在
  • 我以后再给代码写注释和文档;[如果需要,就现在

 

原问答贴有 72 个回复,摘编部分如下:

00. 我以后再给代码写注释和文档。(Steven Tucci,计系学生,338 票)

如果代码不足以让别人看懂业务逻辑,就请现在注释;注释不够说明情况,就今天记录好文档

不要拖延

 

01. 这只是个临时方案,不会用在实际版本中。 (Clarence Leung,JS 开发人员,186票)

永远把开发的版本当作发布版本

 

02. 搞定了!只剩一些小事要处理。(Brian Luczkiewicz, CMU 计系研究生,140 票)

没做完,就不要说搞定了

 

03. 那个简单,几天就搞定了。(Philip Chu,软件和游戏开发人员, 87 票)

先分析,再确定计划,然后将计划告诉manager。不要觉得自己很屌

 

04. TODO (Chander Shivdasani,程序员、驴友、、美食家 72 票)

05. 就改一行代码,不会影响其他东西的。(Steven Frank ,22 票)(推荐阅读:《6天时间修改1行代码》)

不要轻易下结论,一定要全盘评估后,给出可能的风险,然后自己评估“可能”的可能性

 

06. 在我机器上好好的……(Max Xu MengXiang,AI 学徒,50 票)

完成后,自己要充分测试

07.

  • 开发人员:这个需要10天做完
  • 老        板:你5天可以做完么?
  • 开发人员:可以! - (Muhammad Nasrullah,电子商务公司 CTO,38票)

 

1)计划要认真评估

2)计划一定要包含测试时间

3)计划一定要包含非预测性事件,即在原有计划上加上1到2天,才是最终计划

4)计划定了后,不要轻易更改

 

08. // 这不可能发生:(Richard H. Schwartz,程序员,  24 票)

1)不可能发生的逻辑不需要存在于代码中;

2)如果真的发生了,你能做的,是调试。

 

09. 我不用给那程序测试,我已经知道它可以奏效!(William Pietri,作家. 22票)

你不能确定将来发生什么,即使代码都是你自己写的

 

10.对,这是一个已知 Bug。(Gaurav Gupta,亚马逊工程师, 24票)

我觉得这句话不可以给直接上司意外的任何人说,只有计划有变时间不够的情况下才会发生。

或者经过调试后说,哦,这确实有个bug。

 

  1. 下次修改代码时我会增加单元测试。 (Cosmin Negruseri,Google 员工, 26票)

如果正式的大项目,单元测试是有必要的。

 

  1. 我已经完成 90% 了。(Alex Feinberg,17 票)

我还没完成,或者我完成了具体哪些工作,或者说我还有哪些工作没完成

 

  1. “这个两分钟就可以修复的!” (Dhruv Hari Baldawa,15 票)

你这样说,我不会觉得你很屌。这个我先调试下,如果需要很短时间,修复了再反馈;如果需要很长时间,反馈多久可以修复。

 

  1. (适用于嵌入式开发人员:)“这是硬件问题。和软件木关系!” (Naveen Jain,嵌入式工程师, 11票)

(我不是嵌入式开发)

 

  1. 这不是 Bug,这是特性!(Yuriy Goldman ,7 票)

你很屌!!

 

19. 我没有偷懒,我的代码在编译着呢!(Benjamin Schak,8 票)

不要在上班时间干其他事情,即使你觉得别人不会知道

 

  1. 昨天还好好的啊!(Prathab Kali,12 票)

承认和接受就好了,现在就是坏的,我会调试后回复你

 

  1. 在我机器上好好的!(Chirag Darji ,3 票)

承认和接受就好了,现在就是坏的,我会调试后回复你

 

  1. 这 Bug 不在我代码中,你肯定使用姿势不对啊!(Kamal Aboul-Hosn,程序员、鼓手、摄影师, 4 票)

哦,是的,我是睡着写代码的

 

posted @ 2014-12-05 13:35  Tony二师弟  阅读(414)  评论(0编辑  收藏  举报