《程序员的十大烦恼》由会员分享，可在线阅读，更多相关《程序员的十大烦恼（5页珍藏版）》请在金锄头文库上搜索。
1、程序员的十大烦恼每个程序员都有自己烦恼的事。不论这事指的是范围蠕变(scope creep)， 还是指匈牙利变量命名 (Hungarian notation)，还是有臭味的同事，我们都明 白，这是我们有我们行业里的特定的烦恼。 下面要说的就是十大让程序员们烦 恼的事情，这是我从最近的在 StackOverflow 上的一个调查里整理出来的，并 且掺杂了一些我个人的经验：1.1. 注释注释 只解释了只解释了“how”“how”却没有解释却没有解释“why”“why”入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注 释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释
2、好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。 这就是为什么会经常看到像 Jeff Atwood 在他的博客文章 Coding Without Comments 提到的代码：r = n / 2; / 让 r 等于 n 除以 2 / 当 r - (n/r) 大于 t 时进行循环 while ( abs( r - (n/r) ) t ) r = 0.5 * ( r + (n/r) ); / 设置 r 等于 r + (n/r) 的一半 经过这样的注释，你否明白了这段代码是干什么的?的确，我也没明白。 问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有 说
3、明代码为什么要这样写。现在，请看一下我们采用另外一种方式对同一段代码进行的注释:/ 使用牛顿-Raphson 算法求 n 的平方根近似值 r = n / 2; while ( abs( r - (n/r) ) t ) r = 0.5 * ( r + (n/r) ); 这就好多了!也许我们还是不能完全明白这段代码的作用，但至少是有了一 点方向了。注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认 为，读者对 for 循环的工作原理是了解的;所以没必要写这样的注释：“/ 对 客户列表进行 for 循环操作”。读者不明白的是你的代码是做什么用的，你为 什么要采用这种方式实现它。2.2
4、. 干扰干扰很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况 下，我们更类似于需要慢慢启动的火车，而不是能突然加速的 法拉利; 我们需 要一定的时间才能进入工作状态，一旦我们进入稳定有效的工作状态，我们的 工作效果和产出会很丰硕。不幸的是，当思路不断的被客户、经理、以及你的 同事打断时，你的大脑很难进入编程的状态。当我们干一件事情时，有太多的琐事需要我们放在心里，我们需要先放下 这个事情，处理那个人事情，回头又干这个事情，还不能有差错。这些干扰会 中 断我们的思路，而重新整理清楚思路又要你花费大量的时间，这是让人懊恼 的、没有比这更让人泄气、让人有挫折感的过程了。3.3. 范围
5、蠕变范围蠕变(Scope(Scope creep)creep)来自 Wikipedia 的解释：范围蠕变(Scope creep) (也称作焦点蠕变(focus creep)，需求蠕变 (requirement creep), 功能蠕变(featurecreep)，以及其它一些乱七八糟的演 变词语)，指在项目管理里项目的需求变更失控。当一个项目的范围没有明确的 定义清楚、没有文档化、不受控时就会出现这种现象。这通常被认为是一种有 负面影响的事情，应该尽力避免。范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨 无霸。那些负责需求调研的家伙们只需要敲几下无辜的HU键盘UH就能把事情
6、变成这 样：版本 1: 显示这个地区的地图版本 2: 显示这个地区的地图，要三维立体的版本 3: 显示这个地区的地图，要三维立体的，而且能够使用它作为飞行 导航图晕倒!一个本来 30 分钟能完成的任务变成了一项要几百人/天才能完成的超 级复杂的系统。更糟糕的是，大多数情况下，需求变更是发生在开发阶段 的， 这样一来你需要重写代码，重新回归，有时要把前几天才开发的代码删除。4.4. 管理者管理者 完全不懂编程完全不懂编程管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、 喜怒无常，我们都自以为天下第一。想让这样的一群人都感到满意和团结，你 需要付出像山一样大的努力。 然而，这并不
7、意味着管理者就可以在对下属的工 作毫不理解的情况下进行管理。当管理者对我们的工作没有一点知识概念时， 后果只会是需求频繁变动，不现实的工期，普遍的挫折感(管理者和开发人员)。 程序员们对此的抱怨相当普遍，这也是产生争执不合的根源(就像一个欢闹的卡 通片).5.5. 写文档写文档在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的 经验，这些工具都是只适合生成 API 文档，以供其他程序员参考。如果你开发 的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服 等)都能理解的文档手册。我们可以很容易的看出，有些事情程序员们极不愿意去做。 你可以简单的 回顾一下所有的开
8、源项目。 人们百折不挠的对这些项目的一个索求是什么：文 档。我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会 说：“不能让其他人去写吗?“。6.6. 程序程序 缺少文档缺少文档我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们 的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像 我在第 6 条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自 己身上。当你需要使用一个第三方类库时发现，至少有一半的 API 无从知道是干什 么好用的，没有任何事情比这个更打击人的了。函数 poorlyNamedFunctionA() 和函数 poorly
9、ButSimilarlyNamedFunctionB() 有什么区别?在我使用 PropertyX 属性前是否需要测试一下它是不是 null 值?我估计只有通过自己的 测试和报错才能弄清楚!可恶。7.7. 硬件硬件任何一个曾经被叫去调试一个数据库HU服务器UH上奇怪的宕机现象，或是被叫 去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时，都 会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知 道如何修理电脑。不可否认，有些程序员确实是个全才，但我估计，绝大部分 程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们 只关心做出来的东西是否符合
10、需求文档，这样我们才能集中精力去解决这上层 的任务。8.8. 含糊不清含糊不清“网站宕机了”. “XX 功能工作不正常”。 处理含糊不清的任务是种痛 苦。 每次当非程序员被要求重现他们所遇到的问题时表现出的愤怒都让我吃惊 不已。 他们似乎不太明白，仅仅一句”它宕机了，修复它!”是无法让我们开 始工作的，我们需要更多的信息。软件的运行是(大部分情况下)有迹可寻的。我们也乐见与此。 请迁就我们， 帮我们指出是在哪个阶段，什么情况下出的问题，而不是简单的说一句”修复 它“。9.9. 其他程序员其他程序员程序员经常和其他程序员合不来。诧异吗，但这是真的。 这方面的事情我 可以轻松的列出十大条，讲细点甚
11、至可以单独写篇博客，所以这里我只列出几 个常见的、让其他同事感到懊恼的程序员的特征：脾气暴躁以至态度极不友好。不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。无法进行有效的沟通，使用易于误解的专业术语。自己的事情处理不好。对要做的程序和项目缺乏兴趣。那么，这最后的，但不是最糟糕的，序号为 10 的让程序员们烦恼的10.10. 自己写的代码自己写的代码 6 6 个月以后的个月以后的Dont sneeze, I think I see a bug.回顾一下自己以前写的代码，是否也会愁眉苦脸?当时怎么会这么愚蠢!怎 么能编写成这样的东西! 烧掉!丢到火里!哈，好消息。你并不孤单。现实是
12、，软件技术界是一个不断变化的世界。 今天被看成是最好的方式， 明天也许就会过时。我们不可能写出完美的代码，因为判断我们的程序好坏的 标准日新月异。这令人很不爽，你的作品，今天看来是那么的完美，但也许不 久之后就会变成被人嘲笑的对象了。真是让人沮丧，因为不论我们如何努力的 学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技 术发展趋势慢了一拍。对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯 (sand-painting)的和尚。好了，全都给写出来了。这十大让程序员烦恼的事情。 依旧，如果你觉得 我的文章里有什么疏漏的地方，请让我知道，欢迎留下评论!
