最令程序员沮丧的 10 件事

软件开发是一个伟大的工作——和任何其他工作一样，它也有它的缺点。下面的10件事就是大多数程序员关于编程所无法苟同的。

对于非软件开发人员来说，开发人员的工作看起来一定很甜蜜：很多公司都需求这方面人才，得到的报酬真的很不错，公司给你各种有趣的福利，等等。但是真相却是，虽然，这一切是真的，但如同任何其他的工作一样，程序员也有那些扒拉着头发恨不得拔光的时刻。在软件工程师的一生中，有许多事情可能会让他或她沮丧不已。

基于在线讨论论坛中程序员的评论和投票，我们总结了最令软件开发人员沮丧的10件事情。如果，读完了这些，你依然不改初衷想成为软件开发人员，那么别说我没有提醒过你。

10.硬件

软件，如果没有硬件供其运行的话，自然无法做任何事情。尽管一些软件开发人员在最后依然自欺欺人地想要忽略硬件，但人力所不可避免的是，迟早，他们会在构建或调试程序时面临特定于硬件的问题。这就是为什么一些程序员强烈建议新的软件工程师熟悉运行代码的底层硬件和系统，以减少未来的交恶。

引用：

“任何曾经被调用来调试数据库服务器上的奇怪崩溃或为什么RAID驱动器不能正常工作的程序员，都知道最后发现是硬件问题的话该是一种怎么样的痛苦。”——Steve Borthwick

“程序员讨厌硬件：因为他们总是不能归咎于硬件！”——匿名

9.整天坐着

除非你有带跑步机的办公桌，否则软件开发肯定不会是一个有氧活动。大多数程序员往往长时间地坐着，蜷缩在键盘上，盯着他们的计算机显示器。虽然说坐着比站着舒服，但总是这么坐着，坐久了就会变得很不舒服。这也是一件令人沮丧的事。

引用：

“整天坐在椅子上，两眼紧盯屏幕。一段时间以后——首先是背部发起了抗议，接下来是颈椎喊不舒服，眼睛又酸又涩，头疼……腿开始不知道怎么安放……正如我试图用健身，打太极拳，练瑜伽，学气功，骑自行车上班来减轻久坐的痛苦——我真的忍受不了一天8+小时的久坐了。整天被困在办公室里……从太阳升起来，再到太阳下山——坐在那把蠢毙了的椅子上，任凭时光流逝。“——Markus Toman

8.调试

即使是最好、最精心设计的代码也会有bug。所以，理所当然地，开发人员必须定期花费时间来跟踪和修复软件缺陷，无论是他们自己的代码还是别人的代码。尽管有些错误可以很快被发现和镇压，但总有不少bug特会躲猫猫，寻寻觅觅，从而耗去了许多小时的开发时间，更不要提程序员的理智何存了。

引用：

“发现一个难以重现的缺陷，在最糟糕的情况下，通过对相同片段的代码进行随机通过和失败的集成测试来表现！你会有这样一种感觉，感觉自己可能永远找不到那些神秘又邪恶的bug潜伏在代码何处。哎呀呀！”——Emmanuel Ngwane

“我们编写这样这样大的程序（有时甚至很小），在调试的时候，我们会钻研得很深入，以至于忘记了原来的bug是什么。”——Ayush Bhatnagar

“调试，特别是当你正在处理涉及成千上万行代码的大项目时。大多数像我这样的极客倾向于使用投影仪调试，因为眼睛会更舒适。“Isaac Perez

“Heisenbug（海森堡bug）。”Awal Garg

7.糟糕的文档

工作于其他开发人员的代码令人沮丧，但如果代码文档良好的话，至少会减少大量厌恶值。不幸的是，情况并非总是如此。如果软件没有很好的注释或缺乏良好的书面说明它是如何工作的，那么就需要耗费很长很长的时间来调试、增强或集成该软件。此外，对程序员的血压也不利。

引用：

“最令人沮丧的事情是被雇用来工作于一个文档糟糕的软件。它让那些接管项目的人步履维艰。缺乏注释以及写得糟透了的语义，尤其是还要面对先前的程序员留下的一堆bug和错误。“——Angel Angeles III

“理解某些白痴写的没有文档和没有注释的代码。”——Abhishek Chauhan

“我，和大多数程序员一样，在维护文档写得不好的代码上花费了更多的时间，而不是在编写新的代码上。”——Walt Karas

6.合并代码

源代码控制系统，如Git或Subversion，是一个很好的工具，因为它允许多个开发人员在同一个代码库上同时工作，而无需顾忌他人。但是，最终，代码更改必须提交到存储库，而且可能会发生冲突，例如如果两个开发人员更改了相同的文件或程序的话。在这种情况下，这些更改必须合并在一起。有时这些合并冲突可以简单地解决，但有的时候，并不是手到擒来那样简单。

引用：

“我也不喜欢合并，因为情况往往会是，你想以这种方式改变代码，而我想以那种方式改变代码，那么我们应该如何改变代码？我总能找到一种方式来整合我们双方的更改，但如果真有冲突的话，那将是一个尴尬的过程。”——Jessica Su

“合并冲突——*呀拉索，那就是地狱恶魔*。”Koustuv Sinha

5.不切实际的期望

软件开发人员通常被认为是相当聪明的人。不幸的是，这种观念往往会导致老板、项目经理和销售人员对程序员或程序员的团队在某个日期内可以合理生产的东西产生不切实际的期望，并对可交付的成果过度承诺。反过来，这可能导致开发人员倦怠，使程序员间弥漫不爽不愉悦的氛围。

引用：

“最令人沮丧的事情是，让人们醒悟错误的看法——我真的不是魔法师，我的知识基础有局限，使用可用工具在限定时间内完成的工作是一定的，以及试图向那些从来没有编程过的人解释什么是约束，真的好烦。”——Mark Miller

“你的老板对你和你的同事有很高的期望，但没有提供足够的时间/资源来满足这些期望，甚至是靠近这些期望。”——Kevin Sekin

“项目经理或业务分析师向客户承诺给月亮，然后程序员必须这样做，不行也得行。”——Ratnakar Sadasyula

“我喜欢这样子，当有人问一些微不足道的事情时，就随便抛出一个功能，而这个功能需要用几十年时间推进CompSci领域来实现。”——Vladislav Zorov

4.其他人破坏我的代码

每个开发人员的代码，在某些时候，必须与其他开发人员编写的代码协同工作。无论是相同软件片段的不同部分，第三方库或工具，还是另一个完全不同的应用程序，没有一个开发人员的代码是一座孤岛。于此产生的不幸是，这意味着在匆忙中，因为不良的沟通或者粗心大意，程序员可能会破坏另一个程序员的代码，从而引发紧张、压力、以及通常还会伴随咒骂。

引用：

“我曾经经历过的最悲催的沮丧是与另一个人共同编写一个程序，他改变了我们需要链接的库而没有告诉我。这意味着我对例程的调用缺少了变量或者添加了变量，甚至更糟的是，代码会在我没有访问的库中崩溃。”——Sheri Fresonke Harper

“如果你的代码部分停止工作是因为其他人改变了他们的代码部分。那么通常他们的函数使用了比以前更多的参数。有时，参数被完全消除或被放置在不同的文件中。”——Jessica Su

“不断地返回去返工你几天前才写的东西，原因是你写的东西’坏掉了’（第n次）——由于其他人（没有讨论）在实现改变更广泛的系统时，或者不测试或者不在乎测试失败——你听到的第一件事是“你的代码坏掉了”。”——Simon Hayes

3.人们不明白我是做什么的

尽管软件开发人员的数量明显在不断增加，更不用说我们所使用的一切对软件的依赖性也在增加，许多非技术人员仍然不明白软件开发人员究竟是干什么的。对于非技术人员来说，开发人员就是“技术人员”，而没有考虑到软件工作者和硬件工作者之间的区别。持续的误解和错误的期望，特别是来自于家人和朋友的期望，真的会让程序员抓狂。

引用：

“非技术人员似乎有一个常见的误解——既然程序员使用电脑，那么我们肯定知道如何修理它们；这种想当然的看法有点像——假设Jenson Button知道如何驾驶F1赛车，那么他也一定知道如何拆卸和重新组装一个赛车齿轮箱。”——Steve Borthwick

“是的，我以写代码谋生；但是，对于打印问题或你打不开的配件或无法启动的笔记本电脑，请恕我无能为力。除非你请我吃饭或请我喝啤酒，那么也许我可以提供帮助。”——Phil J

“向人们解释我不是安装盗版操作系统和其他盗版软件的。”——Anbalagan Jeyabalachandran

“家人和朋友认为你可以修复任何与电脑相关的东西。无论是硬件还是软件。他们不在乎。最后他们反而会嘲笑[你]。类似于：“既然你不能修复笔记本电脑的DVD光盘，那你算什么软件工程师？”——Jazib Babar

“1%-2%的人知道你是做什么的。”——YasinPekşen

2.缺乏时间

像大多数工作一样，制作好的软件需要时间。不幸的是，在大多数努力中，上级管理者和/或客户通常不愿意等待很长时间，就想得到可正确实现的理想解决方案。因此，软件开发人员常常被迫快速完成某些工作，而这可能会导致攻击，技术债务和文档缺乏，所有这些都可能会造成更多令人头痛的问题，特别是对于那些将来不得不处理这些代码的程序员而言。

引用：

“我想办好事情，但是快速、熟练做事方面就会产生很大的压力。有时它是有道理的，但我感觉当前的编程/商业文化已经在这个方向上走得太远了。”——Tikhon Jelvis

“在我看来，匆匆忙忙编写的代码我称之为拼装代码，当然我也希望产品中的代码我能写得更优雅。但不妙的是，有一个恒定的时间压力…”——Gene Sewell

“当你做的很多事情甚至与你知道的何为良好编程实践毫不相干的时候，但是因为快速比质量更重要，你不得不按他们要求你的那样做。”——Jose Palala

“…时间和资金不够用于正确的解决方案，但却有足够的时间和资金用于修复快速和恶劣的解决方案，一遍又一遍又一遍。”——Romi Awasthy

1.使用其他人的代码

作为一个软件开发人员，迟早，你得使用其他人写的代码。无论是继承先于你工作之人的遗留代码，第三方API，还是由顾问编写的代码，你都不能完全避免修复、增强和/或整合他人程序的问题。当然，这样做会导致开发人员拔掉一些——或很多根——头发。

引用：

“…最糟糕的地方是，你不得不处理一些其他人的代码，找出来，调试它，调整它。更糟糕的是，如果你前面的人已经离开了公司，那么就真的只能靠你自己摸索了。”——Ratnakar Sadasyula

“试着破译成千上万行无注释的代码。”——Simon Zhu

“我曾经多次处理过由顾问编写的特可怕的代码。”——Joe Samson

“另一个我认为可能非常令人沮丧的问题是第三方API。你有时会非常依赖它们，然后你发现了一个问题或需要一个新的功能，但特定的API没有给你任何源来解决这个问题，所以你需要询问API的作者，期盼能有最好的结果。”——Kevin Sekin

“语言和框架bug。你花费几天的时间找出为什么代码不工作的原因。结果却发现不过是触及了语言或框架上的bug。”——John Paul Alcala

“发现找不到一个写的代码不应该远不合格的人…。”——Nani Tatiana Isobel