軟件開發是一個偉大的工作——和任何其他工作一樣，它也有它的缺點。下面的10件事就是大多數程序員關于編程所無法茍同的。

對于非軟件開發人員來說，開發人員的工作看起來一定很甜蜜：很多公司都需求這方面人才，得到的報酬真的很不錯，公司給你各種有趣的福利，等等。但是真相卻是，雖然，這一切是真的，但如同任何其他的工作一樣，程序員也有那些扒拉著頭發恨不得拔光的時刻。在軟件工程師的一生中，有許多事情可能會讓他或她沮喪不已。

基于在線討論論壇中程序員的評論和投票，我們總結了最令軟件開發人員沮喪的10件事情。如果，讀完了這些，你依然不改初衷想成為軟件開發人員，那么別說我沒有提醒過你。

[[179760]]

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

譯文鏈接：http://www.codeceo.com/article/10-things-biggest-frustrations.html
英文原文：The terrible 10: Programmers’ biggest frustrations