最让程序员烦恼的10件事.docx

1. 6 个月后再看自己的代码 别打喷嚏，我发现了一个 bug。 你有没有回过头去看看自己以前写的代码，有没有情不自禁地捶胸顿足？有没有在懊恼自己当初怎么会这么傻逼，写出这种垃圾玩意！删掉，删掉，通通删掉！ 2. 与其他程序员的相处 程序员经常和其他程序员合不来。不要装的很惊讶，内心早承认了吧，亲爱的程序员们。关于这方面的事例我随口就可以列出十大条，甚至可以另外单独写篇博客，所以在本文中我仅列出几个之所以会和同事难以好好相处的常见原因： 脾气暴躁，态度不友好。 不明白什么时候该去讨论系统的架构，什么时候该开工。 无法进行有效的沟通，使用易于误解的专业术语。 自己的事情处理不好。 对代码库和项目兴致缺缺。 3. 含糊不清 “哎呀，我的网站出问题了”、“XX 功能不正常”，这种指向性不明确的要求最 痛苦了。我特别讶异的是，当我们要求那些非程序员重现问题时，他们竟然会愤怒不已。难道他们不知道，仅仅一句“电脑坏掉了，快点修复一下”，我们是没办法开始工作的，我们需要更多的信息。 软件的运行，在大多数情况下，是有迹可循的。我们也喜欢这种方式。请迁就我们， 帮助我们找出是在哪一步出现的问题，而不是简单一句“修复”。 4. 硬件（总是被当成修电脑的） 任何一个程序员要是被叫去调试数据库服务器上一种奇怪的宕机现象，或者去解决 RAID 驱动器不能正常工作的问题，而最后发现却是硬件的原因，orz 都会痛苦不已。话说，不知道哪里来的误解，人们竟然会以为程序员这种整天捣鼓电脑的家伙，肯定知道如何修电脑。好吧，有些程序员确实会修（大概是他们大学 时泡妹子修炼的技能？），但是，我敢打包票，大多数程序员是不知道的，或者对程序被编译成机器码后是如何工作的毫不关心。 我们关心什么呢？我们关心的是我们做出来的东西是否符合需求，这样我们才能集 中精力去解决更高级别的任务. 5. 缺少文档的程序 好吧，我从来没有说过我们程序员是说一套做一套的人。程序员经常被要求在项目中用到第三方的类库和应用。这使得我们不得不需要文档。但是正如我在上面那条说的那样，程序员痛恨写文档。真是个矛盾又纠结啊！ 当我们需要使用一个第三方类库是，却不知道至少有一半的 API 有什么用，没有什么比这个更让人崩溃了。知道函数 poorlyNamedFunctionA ()和 poorlyButSimilarlyNamedFunctionB ()的区别不？当我访问 PropertyX 时是不是需要先做一个 null 测试？如果缺少文档，我估计我得通过自己的测试和错误报告才能知道结果，哦，my god！ 6. 写文档 没错，的确有很多文档生成工具，但我的经验告诉我，这些工具都是只适合生成 API 文档，以供其他程序员参考。如果你开发的软件是很多人在日常生活中都会用到的，那么你最好写一些即使外行人也能理解的文档（例如，应用程序如何工作、故障诊断指南等等）。 好吧，有些程序员可不乐意干这事儿。大家经常做的是，快速浏览开源项目，然后开始不断的搜寻文档来获取帮助。 我敢打保票的说，不管在哪里，几乎所有的程序员被要求写文档时，都会说：“不能让其他人去写吗？” 7. 管理层不懂编程 当然，也会有例外，此点标题仅为个人遭遇，如有雷同，纯属巧合。 首先我们要承认，管理不是个简单活。下属会讨厌你：他们脆弱的内心有时也会受伤。并且要保持一大群人的团结和凝聚力几乎就像是座山一样的任务。然 而，任务艰巨并不意味着管理者能不对他们的下属有一个基本的了解。当管理层无法把握工作理念，就会使员工出现范围蔓延，超出完成期限，感到挫折心情沮丧等 等状况。这是很多程序员在日常工作中经常抱怨和焦虑的根本原因。 8. 范围蔓延 维基百科将范围蔓延定义为“在项目范围内不受控制的变化”。范围蔓延会使得一个相对简单的请求延伸成一个极为复杂和耗时的任务。它就是运用一些看似方便无害的要求蔓延范围，一步一步破坏项目的时间表： 版本1：显示所在位置的地图 版本2：显示所在位置的三维地图 版本3：显示所在位置的三维地图，精确到可以作为飞行导航 9. 各种打搅 在大多数情况下，程序员的思绪比起法拉利更像是火车，需要慢慢启动，也就是说我们得酝酿一下才能进入状态。但是一旦我们全身心投入的时候，就会高效完成很多令人啧啧称赞的代码。只是很不幸的是，这是很难达到的境界，因为我们的思路总是不断受到客户和同事的打搅 10. 注释说明“是什么”，而不是“为什么” 入门级编程课程教导学生要学会频繁且尽早地注释。不可否认在学习编程的起步阶段这方法的确是相当有效的（即使看到最简单的代码行都像天书）。然而许多程序员即使已经从一只小菜鸟长大成一位计算机牛人，也还是把这个习惯给延续了下来。 r = n / 2; // Set r to n divided by 2? ? // Loop