程序员的十大烦恼

发表于:2014-06-03来源:外刊It评论作者:不详点击数: 标签:程序员
每个程序员都有自己烦恼的事。不论这事指的是范围蠕变(scope creep),还是 指匈牙利变量命名 (Hungarian notation),还是有臭味的同事,我们都明白,这是我们有我们行业里的特定的烦恼。

  每个程序员都有自己烦恼的事。不论这事指的是范围蠕变(scope creep),还是 指匈牙利变量命名 (Hungarian notation),还是有臭味的同事,我们都明白,这是我们有我们行业里的特定的烦恼。 下面要说的就是十大让程序员们烦恼的事情,这是我从最 近的在StackOverflow上的一个调查里整理出来的,并且掺杂了一些我个人的经验:

  10. 注释 — 只解释了“how”却没有解释“why”

  入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。 可不幸的是,很多的程序员把这当成了一种任务,对每一行代码都注释一下。 这就是为什么会经常看到像Jeff Atwood在他的博客文章Coding Without Comments提到的代码:

  1 r = n / 2; // 让 r 等于 n 除以 2

  2

  3 // 当 r - (n/r) 大于 t 时进行循环

  4 while ( abs( r - (n/r) ) > t ) {

  5 r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半

  6 }

  经过这样的注释,你否明白了这段代码是干什么的?的确,我也没明白。 问题就在于,虽然有大量的注释,可它们只是描述了代码是干什么了,却没有说明代码为什么要这样写。

  现在,请看一下我们采用另外一种方式对同一段代码进行的注释:

  1 // 使用牛顿-Raphson算法求n的平方根近似值

  2 r = n / 2;

  3

  4 while ( abs( r - (n/r) ) > t ) {

  5 r = 0.5 * ( r + (n/r) );

  6 }

  这就好多了!也许我们还是不能完全明白这段代码的作用,但至少是有了一点方向了。

  注释是用来帮助读者理解代码的,不是用来解释语法的。 我可以大胆的认为,读者对for循环的工作原理是了解的;所以没必要写这样的注释:“// 对客户列表进行for循环操作”。 读者不明白的是你的代码是做什么用的,你为什么要采用这种方式实现它。

  9. 干扰

  很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况下,我们更类似于需要慢慢启动的火车,而不是能突然加速的 法拉利; 我们需要一定的时间才能进入工作状态,一旦我们进入稳定有效的工作状态,我们的工作效果和产出会很丰硕。 不幸的是,当思路不断的被客户、经理、以及你的同事打断时,你的大脑很难进入编程的状态。

  当我们干一件事情时,有太多的琐事需要我们放在心里,我们需要先放下这个事情,处理那个人事情,回头又干这个事情,还不能有差错。这些干扰会中 断我们的思路,而重新整理清楚思路又要你花费大量的时间,这是让人懊恼的、没有比这更让人泄气、让人有挫折感的过程了。

  8. 范围蠕变(Scope creep)

  来自 Wikipedia 的解释:

  范围蠕变(Scope creep) (也称作焦点蠕变(focus creep), 需求蠕变(requirement creep), 功能蠕变(feature creep),以及其它一些乱七八糟的演变词语),指在项目管理里项目的需求变更失控。 当一个项目的范围没有明确的定义清楚、没有文档化、不受控时就会出现这种现象。 这通常被认为是一种有负面影响的事情,应该尽力避免。

  范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨无霸。 那些负责需求调研的家伙们只需要敲几下无辜的键盘就能把事情变成这样:

  版本 1: 显示这个地区的地图

  版本 2: 显示这个地区的地图,要三维立体的

  版本 3: 显示这个地区的地图,要三维立体的,而且能够使用它作为飞行导航图

  晕倒!一个本来30分钟能完成的任务变成了一项要几百人/天才能完成的超级复杂的系统。更糟糕的是,大多数情况下,需求变更是发生在开发阶段 的,这样一来你需要重写代码,重新回归,有时要把前几天才开发的代码删除。

  7. 管理者 — 完全不懂编程

  管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常,我们都自以为天下第一。 想让这样的一群人都感到满意和团结,你需要付出像山一样大的努力。 然而,这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时,后果只会是需求频繁变动,不现实的工期,普遍的挫折感(管理者和开发人员)。 程序员们对此的抱怨相当普遍,这也是产生争执不合的根源(就像一个欢闹的卡 通片).

原文转自:http://www.vaikan.com/top-10-things-that-annoy-programmers/