最令程序员沮丧的 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