最令程序員沮喪的 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