最让程序员懊恼的10件事

1. 注释说明“是什么”，而不是“为什么”

    入门级编程课程教导学生要学会频繁且尽早地注释。不可否认在学习编程的起步阶段这方法的确是相当有效的（即使看到最简单的代码行都像天书）。然而许多程序员即使已经从一只小菜鸟长大成一位计算机牛人，也还是把这个习惯给延续了下来。

r = n / 2; 

// Set r to n divided by 2

// Loop while r – (n/r) is greater than t

while

 (abs( r – (n/r) ) > t) { 

r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)

} 

看明白上面的代码是啥意思没？

四个字：云里雾里。

上述问题就是，虽然有很多注释，但是却没有说明为什么要写这些代码。下面将上述相同的代码换用另一种注释，那效果就大大不同了。

// square root of n with Newton-Raphson approximation r = n / 2;  while ( abs( r – (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); } 

是不是好多了！虽然我们还是没有完全理解这段代码是什么意思，但是至少我们精简了代码，清爽多了。

    写注释是为了帮助读者理解代码。这里假设，所有阅读代码的人都已经对for循环如何运行有了基本的了解。他们可能不清楚的是，你的代码如何奏效或者你为什么选择这条路径来实现。

2. 各种打搅

    在大多数情况下，程序员的思绪比起法拉利更像是火车，需要慢慢启动，也就是说我们得酝酿一下才能进入状态。但是一旦我们全身心投入的时候，就会高效完成很多令人啧啧称赞的代码。只是很不幸的是，这是很难达到的境界，因为我们的思路总是不断受到客户和同事的打搅。

3. 范围蔓延

    维基百科将范围蔓延定义为“在项目范围内不受控制的变化”。范围蔓延会使得一个相对简单的请求延伸成一个极为复杂和耗时的任务。它就是运用一些看似方便无害的要求蔓延范围，一步一步破坏项目的时间表：

版本1：显示所在位置的地图

版本2：显示所在位置的三维地图

版本3：显示所在位置的三维地图，精确到可以作为飞行导航

4. 管理层不懂编程

    当然，也会有例外，此点标题仅为个人遭遇，如有雷同，纯属巧合。

    首先我们要承认，管理不是个简单活。下属会讨厌你：他们脆弱的内心有时也会受伤。并且要保持一大群人的团结和凝聚力几乎就像是座山一样的任务。然而，任务艰巨并不意味着管理者能不对他们的下属有一个基本的了解。当管理层无法把握工作理念，就会使员工出现范围蔓延，超出完成期限，感到挫折心情沮丧等等状况。这是很多程序员在日常工作中经常抱怨和焦虑的根本原因。

5. 写文档

    没错，的确有很多文档生成工具，但我的经验告诉我，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发的软件是很多人在日常生活中都会用到的，那么你最好写一些即使外行人也能理解的文档（例如，应用程序如何工作、故障诊断指南等等）。

    好吧，有些程序员可不乐意干这事儿。大家经常做的是，快速浏览开源项目，然后开始不断的搜寻文档来获取帮助。

    我敢打保票的说，不管在哪里，几乎所有的程序员被要求写文档时，都会说：“不能让其他人去写吗？”

6. 缺少文档的程序

    好吧，我从来没有说过我们程序员是说一套做一套的人。程序员经常被要求在项目中用到第三方的类库和应用。这使得我们不得不需要文档。但是正如我在上面那条说的那样，程序员痛恨写文档。真是个矛盾又纠结啊！

    当我们需要使用一个第三方类库是，却不知道至少有一半的API有什么用，没有什么比这个更让人崩溃了。知道函数poorlyNamedFunctionA()和poorlyButSimilarlyNamedFunctionB()的区别不？当我访问PropertyX时是不是需要先做一个null测试？如果缺少文档，我估计我得通过自己的测试和错误报告才能知道结果，哦，my god！

7. 硬件（总是被当成修电脑的）

    任何一个程序员要是被叫去调试数据库服务器上一种奇怪的宕机现象，或者去解决RAID驱动器不能正常工作的问题，而最后发现却是硬件的原因，orz都会痛苦不已。话说，不知道哪里来的误解，人们竟然会以为程序员这种整天捣鼓电脑的家伙，肯定知道如何修电脑。好吧，有些程序员确实会修（大概是他们大学时泡妹子修炼的技能？），但是，我敢打包票，大多数程序员是不知道的，或者对程序被编译成机器码后是如何工作的毫不关心。

    我们关心什么呢？我们关心的是我们做出来的东西是否符合需求，这样我们才能集中精力去解决更高级别的任务。

8. 含糊不清

    “哎呀，我的网站出问题了”、“XX功能不正常”，这种指向性不明确的要求最痛苦了。我特别讶异的是，当我们要求那些非程序员重现问题时，他们竟然会愤怒不已。难道他们不知道，仅仅一句“电脑坏掉了，快点修复一下”，我们是没办法开始工作的，我们需要更多的信息。

    软件的运行，在大多数情况下，是有迹可循的。我们也喜欢这种方式。请迁就我们，帮助我们找出是在哪一步出现的问题，而不是简单一句“修复”。

9. 与其他程序员的相处

    程序员经常和其他程序员合不来。不要装的很惊讶，内心早承认了吧，亲爱的程序员们。关于这方面的事例我随口就可以列出十大条，甚至可以另外单独写篇博客，所以在本文中我仅列出几个之所以会和同事难以好好相处的常见原因：

脾气暴躁，态度不友好。

不明白什么时候该去讨论系统的架构，什么时候该开工。

无法进行有效的沟通，使用易于误解的专业术语。

自己的事情处理不好。

对代码库和项目兴致缺缺。

    这还不是最糟糕的，还有个重量级的“程序员杀手”——No.1在后面呢……

10. 六个月后再看自己的代码

    别打喷嚏，我发现了一个bug。

    你有没有回过头去看看自己以前写的代码，有没有情不自禁地捶胸顿足？有没有在懊恼自己当初怎么会这么，写出这种垃圾玩意！删掉，删掉，通通删掉！

    好吧，你可以开心一下，这种事并不单单发生在你身上。

    我们的编程世界是在不断变化的。今天或许是最棒的技术，明天搞不好就过时了。我们永远写不出完美的代码，因为评价的标准也在随着时代的进步而不断提高。无论我们写出来的代码现在看来是要多完美有多完美，但是很可能在不久之后就是被人嘲笑的对象了。

    这的确让人情不自禁的沮丧，因为即使我们现在怎么努力去学习最新最棒的开发工具、设计、框架，以及开发方法，我们总是比最新的技术发展趋势慢了一步。于我而言，这是作为一个程序员最为懊恼的事情了，没有之一，所以我把这一条列为No.1。我们能做的就是不断更新自己的技术，不过有时候，我却会觉得我就像是个搞沙雕的，不断推到重做，呵呵。