<p>软件开发是一个挺不错的工作，不过同时也像任何其他工作一样有着不好的一面。这里列出了大部分程序员对于写代码无法忍受的 10 件事。</p>    <p>对于非程序员来说，他们的工作看起来非常幸福。需求很高、待遇很好，公司提供各种各样的补贴福利等等。然而实话实说，虽然以上所说都不为虚，这份工作就像其他任何工作一样充满了让程序员们抓狂地扯下仅存的几根头发的烦恼。一天当中可以有好几件事能把一个普通程序员逼迫到处于崩溃的边缘。</p>    <p>基于来自在线论坛里真实程序员们的评论和投票，请浏览十大程序员最感到沮丧的事。如果看过之后，你还对成为他们的一员执迷不悟的话，请别说没有被警告过哦。</p>    <h3>10、硬件</h3>    <p>在没有了赖以生存的硬件之后，软件当然是什么也干不了的。尽管一些程序员愿意去忽略硬件端，但他们不可避免地或早或晚会在搭建或者调试程序时面对硬件特定性的问题。这是为什么有些程序员，强烈建议新程序员们熟悉他们代码之下底层的硬件和系统，来减少未来类似问题的恶化。</p>    <p>网友的遭遇：</p>    <p>“任何一个曾经被呼叫来调试一个诡异的数据库服务器崩溃，或是为什么 RAID 驱动程序没有正常工作的程序员，都知道处理硬件问题是多么痛苦。” <a href="/misc/goto?guid=4959727818301146693" rel="nofollow,noindex">Steve Borthwick</a></p>    <p>“程序员痛恨硬件：因为他们不能总是指责硬件。” 匿名</p>    <p>「 <a href="/misc/goto?guid=4959727818393402467" rel="nofollow,noindex">我跳槽是因为他们的显示器更大</a> 。」</p>    <h3>9、一坐一天</h3>    <p>除非你有一个跑步机功能的办公桌，软件开发的工作基本不是一个有氧健身活动。大部分程序员长时间坐着，弯腰驼背地操作着键盘，目不转睛地盯着电脑屏幕。所有这一切只需一会儿就会变得不舒适。如果你不至少换换在哪里坐着，这也能变得非常压抑。</p>    <p>网友的遭遇：</p>    <p>“坐在一把椅子上一整天并且盯着屏幕。一段时间之前毛病开始了。一开始是背，然后是脖子，接下来眼睛开始灼伤疲劳，脑袋开始疼…人开始坐立不安…即便我开始用健身，打太极、瑜珈、气功、骑自行车去上班。我也不能再每天八个多小时这样坐着了。一整天困在办公室里…看着太阳朝升夕落，却仍然坐在那把傻了吧唧的椅子上虚度光阴。” <a href="/misc/goto?guid=4959727818487295308" rel="nofollow,noindex">Markus Toman</a></p>    <p>伯乐在线推荐阅读：《程序员的常见健康问题》。</p>    <h3>8、调试程序</h3>    <p>即使是最好的，最小心翼翼打造出来的代码也免不了错误。自然而然的，开发者们必须经常地花费时间追踪并且修复软件的 Bug；不管源自自己的代码还是别人的 。有些错误能被迅速发现并修复，其他的隐藏得太深，可能会令人发狂，进而导致浪费了数小时宝贵的开发时间，更别说因此损失的码农的理智了。</p>    <p>网友的遭遇：</p>    <p>“发现一个难以重现的 Bug，甚至更糟，一组相同的代码在集成测试中随机地通过或失败！之后你就会感觉你可能永远也不会发现那些神秘潜伏在某处着的恶魔代码。WTF！” <a href="/misc/goto?guid=4959727818577646994" rel="nofollow,noindex">Emmanuel Ngwane</a></p>    <p>“我们写出了如此庞大的程序（甚至有时很小的程序），以至于当调试过程中我们去睡觉之后，我们遗忘了当初的错误是什么。” <a href="/misc/goto?guid=4959727818661090986" rel="nofollow,noindex">Ayush Bhatnagar</a></p>    <p>“调试程序，特别是当你在一个包含了上千行代码的大项目里工作时，大多数的极客（比如我）倾向于用一个投影仪来调试。因为我们的眼睛会舒服多了。” <a href="/misc/goto?guid=4959727818742270817" rel="nofollow,noindex">Isaac Perez</a></p>    <p>“Heisenbugs /海森堡(不确定原理)。” <a href="/misc/goto?guid=4959727818829876380" rel="nofollow,noindex">Awal Garg</a></p>    <h3>7. 拙劣的文档</h3>    <p>与其他开发者的代码共事可能令人沮丧。不过如果代码至少有个清晰的文档，那就不会那么的令人讨厌。不幸的是实际情况不总是这样。那些注释蹩脚，亦或是缺少文字描述如何工作的软件，想要调试、增进、或者整合这些软件所需要的时间大大延长。更进一步来说，这对程序员的血压更是有害无益。</p>    <p><img src="https://simg.open-open.com/show/4dc0e0a70cedda491d532e335108ff24.jpg"></p>    <p>网友的遭遇：</p>    <p>“最令人沮丧的事就是被雇佣来为一个文档拙劣的软件工作。这使得接受的人举步维艰。它们缺少注释，有着糟糕的代码语义，尤其是当前面的程序员们留下了一大堆缺陷和错误。” <a href="/misc/goto?guid=4959727818911285137" rel="nofollow,noindex">Angel Angeles III</a></p>    <p>“理解某个白痴写的没有文档没有注释的代码。” <a href="/misc/goto?guid=4959727819002850520" rel="nofollow,noindex">Abhishek Chauhan</a></p>    <p>“我跟绝大多数程序员一样，大部分时间花在了维护缺乏文档的代码上，而不是编写新的代码。”   <a href="/misc/goto?guid=4959727819088520424" rel="nofollow,noindex">Walt Karas</a></p>    <p>伯乐在线推荐阅读：《 <a href="/misc/goto?guid=4959727819166901836" rel="nofollow,noindex"> 从 <strong>程序员</strong> 到项目经理（29）：怎样写 <strong>文档</strong> </a> 》</p>    <h3>6. 整合代码</h3>    <p>源代码控制系统，比如 Git 或 Subversion，是使得多个开发者同时操作同一份代码的绝佳工具，避免了大家互相掣肘。可是，最终代码的改变需要提交到版本库里。此时冲突可能发生，比如说两个程序员修改了相同的文件或者子程序。在这些情况下这些修改需要被整合起来。有时整合这些冲突可以很快就解决，有时就没有这么乐观了。</p>    <p>网友的遭遇：</p>    <p>“我讨厌整合，因为这就好比，你想这么改代码，我想这么改代码。那么我们到底怎么改呢？我总能找到一个办法合并我们所有的修改。但是如果真的存在一个直接冲突，这将会变成一个尴尬的过程。” <a href="/misc/goto?guid=4959727819258196762" rel="nofollow,noindex">Jessica Su</a></p>    <p>“整合冲突纯粹是恶魔。” <a href="/misc/goto?guid=4959727819344000726" rel="nofollow,noindex">Koustuv Sinha</a></p>    <h3>5. 不切实际的期望</h3>    <p>软件开发者通常被认为是相当聪明的家伙。不幸的是，这常常导致老板们，项目经理们，还有销售人员对程序员/程序员团队，可以合理地在一个确定时间点之前的产出有着不切实际的期望。因而夸大了可以交付的成果。这反过来可以导致开发者被榨干并且引发了码农们普遍不满。</p>    <p><img src="https://simg.open-open.com/show/1c3a430f16ad7b025529a81cf2c4fb55.jpg"></p>    <p>网友的遭遇：</p>    <p>“你的老板对你和你的同事有着极高的期望，但却远远没有哪怕接近于期待的时间和资源。” <a href="/misc/goto?guid=4959727819429911015" rel="nofollow,noindex">Kevin Sekin</a></p>    <p>“项目经理或者业务分析师们许诺了一个月亮给客户。然后程序员们无论如何被迫得去做出来。” <a href="/misc/goto?guid=4959727819518474118" rel="nofollow,noindex">Ratnakar Sadasyula</a></p>    <p>“我特别喜欢当某个人问了个看似无关紧要的问题，然后就随随便便地抛下了一个需要计算机科学领域进步几十年才能满足的特性的时候。” <a href="/misc/goto?guid=4959727819617853017" rel="nofollow,noindex">Vladislav Zorov</a></p>    <h3>4. 别人破坏了我的代码</h3>    <p>每一个开发者的代码在某一刻都必须与其他开发者所写的代码协同工作。不论是同一个软件的不同部分，还是第三方软件库或工具，还是另一个完全的应用。没有哪个开发者的代码是座孤岛。不幸的是，这意味着一个程序员的代码可以通过轻率、糟糕的沟通、或者仅仅是简单的疏忽大意，破坏了另一个程序员的代码。这能引起紧张、压力、以及更常见的诅咒。</p>    <p>网友的遭遇：</p>    <p>“我经历的最令我沮丧的事，是和别人一起写一个程序。他擅自更改了我们二人都连接使用的工具库，而没有告知我工具库已经被修改。这意味着我在呼叫着缺少或者增加了参数的子程序，或者更糟糕的情况里，代码会在我没有权限的工具库里崩溃。” <a href="/misc/goto?guid=4959727819702689038" rel="nofollow,noindex">Sheri Fresonke Harper</a></p>    <p>“当你的部分代码因为别人改变了代码而停止工作时。常见的情况是他们的函数使用了比之前更多的参数，有时候程序被完全移除了或者放到了另一个位置。” <a href="/misc/goto?guid=4959727819258196762" rel="nofollow,noindex">Jessica Su</a></p>    <p>“时常被迫退回重改几天前写的现在突然损坏的代码 （第N次），因为更大的系统被某人修改了（没有跟你讨论）。他要么没有进行测试，要么不介意测试失败了。你听到的第一句话就是‘你的代码有问题。’” <a href="/misc/goto?guid=4959727819809609342" rel="nofollow,noindex">Simon Hayes</a></p>    <h3>3. 非技术人员不懂我的心</h3>    <p>尽管软件开发者的数量与日俱增，更不用提我们日常所需的一切都愈发依赖着软件。很多非技术背景的人仍然不理解软件开发者到底在做什么。对于非技术背景的人们来说，开发者们就是一群“技术人员”。很少有人关注，比如说那些开发软件和开发硬件的人的区别。这些随处可见的误解和错误的期待，尤其是来自家庭和朋友，可以真的逼疯一个程序员。</p>    <p>网友的遭遇：</p>    <p>“非技术人员的一个常见误解就是，既然程序员整天和电脑打交道，那我们一定知道怎么修理电脑。这就好比：迈凯轮车队简森·巴顿知道如何拆解和组装一个赛车齿轮箱，仅仅因为他会开 F1 赛车。” <a href="/misc/goto?guid=4959727818301146693" rel="nofollow,noindex">Steve Borthwick</a></p>    <p>“嗯，我是写代码为生的。但我帮不了你的打印问题或者打不开一个附件或者笔记本无法开机。除非你愿意请我一顿午饭或者一瓶啤酒。那么也许我能帮上忙。” <a href="/misc/goto?guid=4959727819901443961" rel="nofollow,noindex">Phil Johnson</a></p>    <p>“要给人们解释我可不是在街角开一个店，给他们安装盗版操作系统和软件到电脑上的人。” <a href="/misc/goto?guid=4959727819993570174" rel="nofollow,noindex">Anbalagan Jeyabalachandran,</a></p>    <p>“家人朋友们认为你可以搞定任何和电脑有千丝万缕联系的问题。不管是硬件还是软件。他们才不关心。你最终变成了听他们奚落。比如‘，如果你连我的 DVD 盘都修不好，那你算什么软件工程师。’” <a href="/misc/goto?guid=4959727820076021357" rel="nofollow,noindex">Jazib Babar</a></p>    <p>“1% 到 2% 的人知道你真的在做什么。” <a href="/misc/goto?guid=4959727820170339815" rel="nofollow,noindex">Yasin Pekşen</a></p>    <h3>2. 缺少时间</h3>    <p>像其他大部分费劲的事一样，打造好的软件需要时间。不幸的是，又像大部分费劲的事一样，上层管理层与/或客户经常不愿意为了一个理想的解决方案正确实施而长时间地等待。结果软件开发者经常被逼着把某件事快点搞定。这将导致丑陋的做法、技术债，并且缺少文档。这些都会在未来引发问题，特别是那些将来要被迫面对这些代码的程序员们。</p>    <p>网友的遭遇：</p>    <p>“我想把事情做好。但是对于把事情快点做完，按熟悉的方法做有着巨大的压力。有时这是常理之中。但这感觉如今的程序/商业文化已经偏向那个方向太多了。” <a href="/misc/goto?guid=4959727820251670411" rel="nofollow,noindex">Tikhon Jelvis</a></p>    <p>“对我来说这就像赛跑一样，写出来我称之为拼凑代码的代码，然后在生产中意识到我真希望当初写得更优雅一些。这里面有一个持续的时间压力…” <a href="/misc/goto?guid=4959727820341425541" rel="nofollow,noindex">Gene Sewell</a></p>    <p>“当你做了许多你甚至不认为和好的编程习惯沾一点边的事情时候，这是因为快比质量更为重要。你必须照着被要求的去做。” <a href="/misc/goto?guid=4959727820430257334" rel="nofollow,noindex">Jose Palala</a></p>    <p>“从来没有时间和金钱去找到正确的解决方案，但是又足够去找到临时应急的粗制滥造方案。这一切一遍又一遍地重复着。” <a href="/misc/goto?guid=4959727820509976478" rel="nofollow,noindex">Romi Awasthy</a></p>    <h3>1. 和别人的代码一起工作</h3>    <p>作为一个软件开发者，或早或晚，你都将与别人的代码一起工作。不管是继承自工作中前辈的遗留代码，还是第三方API，还是技术顾问写的代码，你不可能完全逃离被迫着去修改、改进、或者/以及整合别人的程序。更不用说被逼着做经常导致开发者扯下一些或很多青丝的事。</p>    <p>网友的遭遇：</p>    <p>“最糟糕的部分就是被迫去浏览别人的代码，搞明白、调试好、反复调整。更糟糕的是，如果这个写代码的人已经离开了公司，而你当真没有任何相关的知识迁移。” <a href="/misc/goto?guid=4959727819518474118" rel="nofollow,noindex">Ratnakar Sadasyula</a></p>    <p>“尝试去解密上千行没有注释的代码。” <a href="/misc/goto?guid=4959727820616666032" rel="nofollow,noindex">Simon Zhu</a></p>    <p>“我处理过好几次顾问们写得一塌糊涂的代码。” <a href="/misc/goto?guid=4959727820701503921" rel="nofollow,noindex">Joe Samson</a></p>    <p>“另一个我觉得能令人沮丧的问题是第三方的API。你如此仰赖它们。有时你注意到一个问题，或者需要一个新特性，但那个 API 没有给出任何源码去修改。因此你得去友好地问问 API 的作者，然后盼望最好的结果。” <a href="/misc/goto?guid=4959727819429911015" rel="nofollow,noindex">Kevin Sekin</a></p>    <p>“语言和框架的 Bug。你花了几天琢磨为什么你的代码不能工作。结果只发现原来你触发语言或者框架本身的 Bug。” <a href="/misc/goto?guid=4959727820798847455" rel="nofollow,noindex">John Paul Alcala</a></p>    <p>“忍着看那些一群远远没有达到应有水准的人所写的代码。” <a href="/misc/goto?guid=4959727820878604874" rel="nofollow,noindex">Nani Tatiana Isobel</a></p>    <p> </p>    <p>来自：http://blog.jobbole.com/93145/</p>    <p> </p>