1.我能通過(guò)互聯(lián)網(wǎng)解決問(wèn)題
Stack Exchange 一類的網(wǎng)站已成為軟件開(kāi)發(fā)者的工具箱中至關(guān)重要的工具。當(dāng)然也還有很多其他程序員們尋求幫助的論壇。
程序員最頭疼的事，就是貌似無(wú)窮的知識(shí)來(lái)源中其實(shí)并沒(méi)有解決你問(wèn)題的答案。
“在 Stackoverflow 網(wǎng)站看到有人發(fā)了同樣的問(wèn)題，然而逛了半天也沒(méi)找到答案。”—— Jorge Irun
某論壇上點(diǎn)贊最多的答案毫無(wú)用處！”—— Ramchand Rajasekaran
2.鍵盤上最重要的按鍵壞了
不難想象，鍵盤對(duì)于開(kāi)發(fā)人員有著不言而喻的重要性。但同樣地，在開(kāi)發(fā)人員眼中并非所有按鍵都那么重要。尤其是在一些編程語(yǔ)言中，某些按鍵比其他按鍵的使用頻率更高，例如 JavaScript、Perl 和 Objective-C 中的分號(hào)鍵。為了節(jié)約時(shí)間和避免錯(cuò)誤，開(kāi)發(fā)人員愛(ài)用鍵盤的快捷方式，比起鼠標(biāo)，鍵盤的使用則更頻繁。若是軟件開(kāi)發(fā)者夢(mèng)到鍵盤上他最愛(ài)用的按鍵壞了甚至消失了，就深更半夜里冒著冷汗驚醒，你也不必覺(jué)得驚訝。
“我做過(guò)最糟糕的噩夢(mèng)就是分號(hào)鍵壞了。”—— Ali Akbar
敲了n行代碼后才發(fā)現(xiàn) Control 鍵沒(méi)反應(yīng)……”—— Nikesh Shetty
3.網(wǎng)絡(luò)連不上，或者掉線了
一種比較“小眾”的噩夢(mèng)是，某一工具的論壇下線或是出于維護(hù)狀態(tài)從而不能解決問(wèn)題，但更常見(jiàn)的是訪問(wèn)互聯(lián)網(wǎng)時(shí)掉線，無(wú)法接入站點(diǎn)。因?yàn)楫吘钩嗽L問(wèn)論壇這一目的意外，網(wǎng)絡(luò)更像一個(gè)巨大的象鼻，里邊裝滿了有用的東西，比如代碼段、開(kāi)源軟件。如果互聯(lián)網(wǎng)突然掉線了，就會(huì)造成編程團(tuán)隊(duì)間無(wú)法聯(lián)系，你喜歡的在線音樂(lè)播放服務(wù)無(wú)法使用，更不用說(shuō)接入遠(yuǎn)程服務(wù)或是云端有多困難……如果你想嚇唬嚇唬程序員，大喊一聲“沒(méi)有網(wǎng)絡(luò)”就夠了。記得，隨時(shí)準(zhǔn)備好除顫器以便急救。
如果某天互聯(lián)網(wǎng)和谷歌都消失了，那將倒退回與世隔絕、暗無(wú)天日的古代。遇到 bug 我們只能束手無(wú)策。”—— Thoriq Firdaus
4.無(wú)法再現(xiàn)的危險(xiǎn)錯(cuò)誤
為了修復(fù)一個(gè)漏洞，在這之前開(kāi)發(fā)人員必須在開(kāi)發(fā)或測(cè)試環(huán)境中重現(xiàn)導(dǎo)致錯(cuò)誤的情境。如果你夠幸運(yùn)的話，在開(kāi)發(fā)環(huán)境部署前就能診斷、修復(fù)錯(cuò)誤。許多開(kāi)發(fā)人員害怕隨機(jī)出現(xiàn)又無(wú)法在受控環(huán)境中重現(xiàn)的漏洞。這類該死的漏洞會(huì)讓你在重要客戶的面前變得憂心忡忡，坐立不安。這絕對(duì)是程序員的噩夢(mèng)。
只在眾人或重要客戶面前演示時(shí)才出現(xiàn)的漏洞，簡(jiǎn)直讓我……” —— Jeremy Friesner
“在公司時(shí)藍(lán)屏現(xiàn)象從不會(huì)出現(xiàn)第二次，然而一到客戶家里就老出現(xiàn)。” —— Joe Wezorek
5.缺失好的文檔，甚至沒(méi)有文檔
坐下來(lái)理解一段沒(méi)有良好文檔或注釋的已有代碼是很困難的。若是連文檔或注釋都沒(méi)有，那就更糟了。這情況不僅適用于由承繼程序員的第三方編寫的代碼，還適用于同一個(gè)程序員在很久以前寫的缺少良好文檔的代碼。不管是誰(shuí)切分的不帶說(shuō)明文檔的代碼永遠(yuǎn)是個(gè)噩夢(mèng)。
“毫不夸張地說(shuō)，維護(hù)沒(méi)有開(kāi)發(fā)文檔的舊軟件對(duì)我而言就是個(gè)噩夢(mèng)。”—— Sam Sartor
6.糟糕的老板和主管
和其他人一樣，開(kāi)發(fā)人員也會(huì)有愛(ài)管閑事又沒(méi)啥能力的上司。軟件開(kāi)發(fā)者尤其討厭隨意干涉他們代碼的非技術(shù)管理層。有些領(lǐng)導(dǎo)喜歡承諾我們無(wú)法做到的事，低估項(xiàng)目中切分代碼所需的時(shí)間。一想到這樣的領(lǐng)導(dǎo)和技術(shù)決策人，程序員即使在深夜的夢(mèng)里也會(huì)痛哭。
“對(duì)我而言最糟糕的非經(jīng)理莫屬，比牙疼還糟糕。他們自視甚高，還期待我們能提早地滿足客戶的任何需求。這些所謂的經(jīng)理還堅(jiān)信，編程只是小事一樁，代碼就像浮在空氣中似的，可以信手拈來(lái)。” —— Rachit Agrawal
7.他人清晰又漂亮的代碼
對(duì)大多數(shù)程序員來(lái)說(shuō)，他們喜歡也必須在別人的代碼上繼續(xù)工作；但別忘了，不同的定時(shí)器代碼永遠(yuǎn)不會(huì)一模一樣，不是嗎？甚至是一段有良好文檔的第三方代碼也會(huì)變成一件麻煩事。它要求你做調(diào)試，重構(gòu)，或結(jié)構(gòu)化，使代碼適應(yīng)可能幾個(gè)月前就已切分好的代碼。這些工作會(huì)讓程序員們心跳異常。若沒(méi)有，真是謝天謝地。
8.項(xiàng)目里的要求變更
無(wú)論何時(shí)，軟件開(kāi)發(fā)者都青睞那些闡述清晰、不能變更的應(yīng)用需求。在實(shí)踐中，很多需求都是匆忙制定的，有時(shí)候甚至已經(jīng)成為了正式形式；要求變更的原因，一部分是有糟糕的項(xiàng)目經(jīng)理，另一部分則是來(lái)自上級(jí)或客戶本身的抱怨和干涉?？傊?，不論什么原因，對(duì)需求變更的恐懼——尤其是在最后一分鐘要求變更——永遠(yuǎn)是開(kāi)發(fā)者的心頭恨。
9.消失不見(jiàn)的代碼
無(wú)論開(kāi)發(fā)者花了多長(zhǎng)時(shí)間來(lái)調(diào)度軟件，如果代碼被意外清除了，一切努力都將付諸東流。代碼意外消失的原因有許多，最主要的是鬼使神差地忘記保存文件，或者未知的惡意漏洞導(dǎo)致無(wú)法保存。無(wú)論出于什么原因，不管是不是考慮不周，程序員永遠(yuǎn)都害怕花了大量時(shí)間精力才得出的算法和函數(shù)毀于一旦。
10.IE 瀏覽器
程序員常常會(huì)對(duì)某些技術(shù)忍無(wú)可忍。舉個(gè)例子，Web 開(kāi)發(fā)人員對(duì)用 IE 做開(kāi)發(fā)感到萬(wàn)分恐懼。盡管它仍是最受歡迎的瀏覽器之一，IE 對(duì)于Web 開(kāi)發(fā)者就是噩夢(mèng)。糟糕的是，比起現(xiàn)代、環(huán)保的新版本，舊版本的 IE 不友好，用戶多，還需要更多支持。如果說(shuō)電影“13號(hào)星期五”中殺人狂 Jason Vorhees 嚇倒了一眾Web 開(kāi)發(fā)者的話，他的面具恐怕就是 IE 圖騰。
11.身體不適
編程不是個(gè)體力活兒，但正如其他需要沒(méi)日沒(méi)夜地在計(jì)算機(jī)上切分?jǐn)?shù)據(jù)的職業(yè)那樣，胳膊、手掌、指頭不靈便都很難完成這項(xiàng)工作。任何對(duì)視力、理性思考能力有消極影響的因素，都會(huì)成為大麻煩。因此，軟件開(kāi)發(fā)者的典型噩夢(mèng)是：無(wú)法使用，甚至喪失了身體的某一或某些重要部位——個(gè)人傷害律師（Personal injury lawyer） Baca Raton 如是說(shuō)。
12.我的漏洞傷害了他人
任何軟件開(kāi)發(fā)者都會(huì)成為漏洞的制造者。但并非所有的漏洞都具有同等的災(zāi)害性。其中一些漏洞討人厭但無(wú)害，另一些則會(huì)給公司或客戶帶來(lái)?yè)p失，負(fù)責(zé)開(kāi)發(fā)的人員會(huì)被開(kāi)除。不過(guò)最壞的情況是，漏洞造成了生理上的傷害，甚至危及他人的生命安全。
13.段錯(cuò)誤
程序員中普遍害怕的噩夢(mèng)還有遭遇段錯(cuò)誤。這一錯(cuò)誤由內(nèi)存違法訪問(wèn)而引發(fā)。也就是說(shuō)，程序企圖訪問(wèn)受限的內(nèi)存，或者執(zhí)行某個(gè)受限的行為。一般而言，在這種情況下訪問(wèn)內(nèi)存單元將通知操作系統(tǒng)，進(jìn)而反過(guò)來(lái)通知有問(wèn)題的，大多數(shù)以掛馬程序?yàn)榻Y(jié)束的進(jìn)程。開(kāi)發(fā)人員最頭痛的就是要找到引發(fā)這一問(wèn)題的原因。因此，程序員的噩夢(mèng)里還有段錯(cuò)誤。
