 |
VOOZH | about |
|
VOOZH | about |
一年一度的萬聖節即將來臨，如果大家希望讓自己的軟體開發者好友們真正感受到恐怖氣氛，那就別再搞女巫、鬼魂或者連環殺手那種俗套伎倆了——下面這些狀況絕對會把他們嚇得魂不附體。
網際網路無法回答我的問題
以Stack Exchange為代表的開發者常見問題解答網站已經成為技術從業者們不可或缺的重要資源儲備與依賴對象。當然，也有不少其它問答網站及開發者論壇能夠幫助軟體開發人員解決自己在編程過程中遇到的具體問題。但在少數情況下，開發人員可能仍會遇上那種令自己全身冰冷的可怕狀況：網絡上看似無窮無盡的編程知識儲備依舊沒辦法解答自己的疑問。
@Jorge Irun：「最可怕的就是打開Stackoverflow網站並看到一篇其他人發布的、與自己想問的問題完全一致的帖子。恐怖的是，這篇帖子已經發布一年多了，而且根本沒人做出過回復。」
@Ramchand Rajasekaran：「我害怕的是StackOverFlow上的最佳答案實際上並不起作用（我們也遇上過這種情況）！」
@Steve Traugott：「在谷歌上搜索能解決架構難題的方法，卻發現找到的相關信息已經是六年之前的、描述的問題完全相同——而且就是由我自己發表的。」
最重要的鍵盤按鍵損壞或者丟失了
不用說，鍵盤在程式設計師的日常生活當中扮演著非常重要的角色。但是，並非鍵盤上的每個按鍵對於開發人員來說都擁有或者能夠創造同樣的價值。一部分按鍵的使用頻率要明顯高於其它按鍵，具體情況則視程式語言的類型而定——例如在JavaScript、Perl以及Objective-C當中，分號就意義重大。程式設計師們還喜歡大量使用快捷鍵操作，利用這些組合來代替相對繁瑣的鍵盤、滑鼠或者觸控板操作不僅能夠節省時間、也可以避免多次重複動作帶來的關節勞損。有鑑於此，我們就能想到當開發人員夢見鍵盤上一個又一個心愛的按鍵消失不見、並因此帶著一身冷汗從床上驚醒時，內心該有多麼恐慌與絕望。
@Ali Akbar：我做過的最可怕的噩夢就是自己的分號怎麼按都不起作用。」
@Vivek Patel：空格鍵失靈」
@Nikesh Shetty：「正在編寫一套規模龐大的代碼項目，然後突然發現Control鍵沒有反應了……」
@Nirwan Dogra：「CTRL+Z無法正常實現撤消操作 :( :(「
網際網路失效——或者出現故障
像Stack Exchange這樣的網站因為故障而無法及時應答程式設計師們的問題是一碼事，但網際網路本身整體失效則是另一碼事——而且後者明顯要更加恐怖，甚至足以令人精神崩潰。畢竟除了回答問題之外，網際網路也塞滿了其它極具實用價值的資源，例如開源軟體以及代碼片段等等。更不用提在沒有網際網路的情況下，訪問遠程或者雲端伺服器將無法實現、沒辦法跟分布式團隊中的其他成員溝通甚至連最喜歡的流媒體音樂服務也用不了，這實在是一場深重的災難。因此，如果大家希望真正讓自己的編碼好友嚇一大跳，那就得找點確實震得住他們的理由——例如「網際網路掛了，什麼網站都上不去了！」對了，如果朋友們因此嚇得口吐白沫，記得幫他們擦一擦。
@Mahanthesh Shadakshari： 「StackOverflow網站當前正處於停機維護當中。」
@Anonymous：「谷歌伺服器陷入永久停機狀態。」
@Thoriq Firdaus：「如果網際網路與谷歌都沒法用了，我們就只能回到過去那個閉塞而恐怖的『黑暗時代』。我們會被困在原地，不知道在遇上特定問題之後應該如何處理。」
@nanda：「說真的，如果網際網路本身崩潰了，那麼開發人員們肯定會停止手頭的工作並開始閒聊家常。哦我的天哪……這太可怕了！」
一個無法重現的嚴重漏洞
為了修復一項漏洞，軟體開發人員們首先必須有能力在開發或者測試環境中重現引發這一問題的狀態。接下來，大家就只能碰運氣、希望引發問題的根源能在影響到生產系統之前被診斷出來並在重複測試中不再出現。很多開發人員最害怕的就是那些看似隨機出現的漏洞，這類問題在可控制環境下幾乎沒辦法確切重現。要讓這類漏洞施展威力，大家最好是能選個最合適的時機——例如在為特別重要的客戶進行運行演示之前。相信我，如果能夠成功完成上述部署，各位的程式設計師朋友肯定嚇得褲子都濕了。
@ Jeremy Friesner：「……漏洞平時根本不出現，而只在當著五百多位與會者的面進行公開演示時發生。」
@Joe Wezorek：「某個無法在內部環境下重現的藍屏問題卻在某位重要客戶的設備上反覆肆虐。」
@Jaimie Sirovich：「某個只會在我自己的計算機之外出現的錯誤，而且僅僅發生在生產體系中——無法在測試環境內予以重現。」
@Ankur Agarwal：「在自己本地伺服器上完美運行的程序/網站一旦上線就開始變得極不穩定。這給人的感覺是伺服器像是無情地玩弄自己，而我們只能讓原本興奮的情緒沉入悲傷的深淵、同時卻又無能為力。」
缺乏完善的說明文檔
想在不藉助完善的說明文檔或者代碼注釋的情況下理解現有代碼實在是難如登天。而如果根本不存在任何說明文檔或者代碼注釋，那麼內容理解的難度又會更上一層樓。上述情況不僅局限於接手自其他程式設計師的已編寫代碼內容，更糟糕的是他們可能是在很久之前編寫出相關片段、而且當時並沒有保留妥善的文檔記錄。這種沒有說明文檔可供參考的代碼，無論當初是由誰編寫而成的，都是一種非常恐怖的存在。
@Pratyush Kumar： 「最可怕的就是在沒有適當說明文檔或者某些無意義標識符不提供相關注釋的情況下對代碼進行調試。這就像是在給別人擦屁股，簡直沒法忍受。」
@Sam Brody：「在項目中扮演繼任者的角色最可怕，面對著糟糕的注釋來解讀另一位編碼者的胡言亂語根本就是件不可能完成的任務。」
@Sam Sartor：「最可怕的是維護十幾年前沒有說明文檔可供參考的代碼。我在處理這類工作時確實做過噩夢。」
@Alok Sharma：「在幾年後的其它項目中發現自己當初編寫的無說明代碼時，我簡直陷入了歇斯底里的狂躁狀態。『當時我為什麼要這麼幹？』『這代碼真是我寫的？』這種感覺就像在自己家中迷了路。」
來自地獄的管理者
任何人，包括程式設計師或者從事其它工作的人士，都不喜歡那種喜歡干涉份外事務或者不夠稱職的管理者。不過軟體開發人員尤其如此，他們最害怕非技術人士向他們打聽關於代碼的問題。管理者通常會誇大項目本身所能實現的效果，過度低估編碼工作所需要的時間並做出一些能讓程式設計師們在睡夢中都不斷抱怨甚至唾罵的離譜承諾。
@randcraw：「無能的高層管理人員和無知的決策者們把自己莫名其妙的討論結果強加給開發者。」
@Anonymous：「我最怕非技術管理者，他們總認為自己有資格來插上一腳——事實上他們關於編碼的全部理解都是十幾年前的老黃曆。」
@Rachit Agrawal：「對我來說，最糟糕的噩夢就是那種喜歡吹毛求疵的管理者，他們總認為自己目前的職位屬於大材小用、並希望在限定時間之前滿足客戶的任何或者全部要求。這類人總把編程人員當成奴隸來看待，而切實起效的代碼應該是像孫悟空那樣憑空從石頭裡蹦出來的。」
@RHSeeger：「我最怕的是被迫對整套系統進行重寫……再次重寫……而且需要使用另一種語言以及完全不同於此前的工作集/框架……一次性完成而非分階段調整（即一次替換一部分，完成後再替換另一部分）……而這僅僅是因為一部分高層管理者認為自己想出的主意才是最好的、其他人的既定方針都是錯的而且需要馬上加以全盤否定。」
對其他開發者的代碼進行清理
軟體開發人員當然不希望處理其他人編寫出來的代碼; 歸根結底，其他程式設計師的代碼永遠不可能像自己親手編寫的那麼出色，對吧？對於剛剛接手的朋友來說，即使是擁有良好說明文檔的第三方代碼也足夠讓他們頭痛一陣子的。只要聽說需要對其他人編寫的代碼——哪怕是幾個月前剛剛編寫完成的——進行調試、重構或者現代化調整，程式設計師們往往會出現強烈的不適反應，例如心律不齊——而且很明顯，這樣的決定往往並不明智。
@bta「……我最怕的是老闆要求我對所謂『擁有原始碼』的項目進行重寫或者現代化調整，因為這種情況下『擁有原始碼』的真實含義往往是『它是用Fortran語言在這堆雜亂無章且數量龐大的穿孔卡片上編寫的』。」
@George Alexander：「……我認為程式設計師可能面對的最惡劣狀況就是負責接手某位前任開發者的原始碼——而這些代碼根本沒有遵循任何標準化或者最佳實踐方案。」
@Giovanni Idili：「我最怕的是被要求『從C++代碼中找出某個與什麼什麼相關的漏洞，而實際可用的素材只是一大摞紙質記錄（長達20頁的代碼，約有2000行命令）而非能夠直接進行編譯、運行以及調試的代碼。 「
@Chip Frank：「如今程式設計師當中的主力是那些通過『編碼一小時』課程入行的菜鳥，而他們留下的垃圾最終還是得由我負責清理。」
變更項目要求
無論是採用傳統的瀑布式項目管理方案還是敏捷環境下以用戶為核心的實施方針，軟體開發人員最需要的就是一套清晰、可靠、穩定且足以指導編碼進程的項目要求。但在現實情況下，這些要求往往會在工作推進過程中出現變更——有時候是出於正當理由，有時候則僅僅是因為愚蠢的項目經理、高層管理者或者客戶腦袋一熱而導致。無論如何，只要出現這種情況，程式設計師就會身陷難以擺脫的恐慌情緒當中、特別是害怕項目結束前的最後一分鐘出現要求調整。
@Basav Nagur：「就在項目進入衝刺階段的前一天，通過電子郵件發來要求變更的通知。」
@Kunal Suri：「特別是在要求變更會對資料庫規劃產生影響的情況下，這實在比給人扭斷了脖子更難受。」
@Yinso Chen：「一切都已經測試完畢並準備好迎接第二天的生產環境部署，這時老闆通知我們原有要求出現了變更、而所有工作都得在今天之內完成。」
@Dave Cahill：「我最怕那種不知道自己想要什麼偏又喜歡定期進行要求變更的客戶，他們會盲目地指手畫腳直到技術團隊徹底崩潰。」
我的代碼憑空消失了
無論開發人員在軟體編寫工作上花了多少時間，如果代碼意外消失、那麼一切努力都將付之東流。原始碼可能出於各種各樣的原因而在轉眼間灰飛煙滅，包括忘記正確保存文件、某些特別惡劣（也特別殘忍）的漏洞以及命運的無情捉弄。無論是何種原因所導致，也不管開發人員多么小心謹慎，事實上程式設計師們一直生活在恐懼當中、害怕自己長期以來用心經營的工作成果在瞬間消失無蹤。
@Philan James： 「由於突然停電或者個人疏忽而導致辛苦編寫的代碼就此丟失。」
@Simon Hayes：「當大家意識到這一點時，糟糕的代碼管理習慣已經導致運行中的程序被從文件系統里徹底擦除（也可能還影響到了與我們工作相關的其他開發人員的編碼成果）。」
@Sakthi Prasad：「我最怕的是自己急於重啟系統，而在面對IDE給出的『尚有未保存的工作，您是否希望將其保存〈是〉，〈否〉』提示時忙中出錯。雖然我們的腦子裡想的肯定是〈是〉，但自己的手指有時候會已經點上了〈否〉——這讓人恨不得直接把它給剁了。」
@Ayush Sekhari：「我最怕的是在錯誤的目錄當中輸入了rm –r *。然後就沒有然後了。「
IE瀏覽器
所有的程式設計師都有自己最畏懼、最沒自信的技術領域，但Web開發人員在這方面的感受卻更強烈也更直接——那就是對於在IE瀏覽器上構建項目的反感甚至牴觸。儘管仍然屬於目前人氣最高的瀏覽器方案之一，IE同時也成為眾多代碼編寫者的口誅筆伐對象。更糟糕的是，IE舊版本不僅問題更多、讓人抓狂的是偏偏還擁有更為龐大的用戶群體。為此，開發人員不得不將其納入支持列表，而且其支持周期往往比其它更具開發者友好特性的瀏覽器更長。我們不妨打這樣一個比方：如果《黑色星期五》電影中的殺人狂傑森想要把一隊Web開發人員嚇得魂不附體，那最好是在自己的冰球面具上貼一張IE的標誌。
@Cem Kaan Kösalı：「最可怕的是：客戶使用IE瀏覽器！」
@Thoriq Firdaus：「開發人員要讓自己的Web應用程式能夠順利運行在IE 6瀏覽器上，花費的時間往往達到為Chrome或者火狐等其它現代瀏覽器開發應用時的四三倍以上。」
@Arvind M.Raman：「我最怕的是在普通代碼已經能夠在人類已知的全部其它瀏覽器上正常運行時，仍然需要利用HTML、CSS以及JavaScript為其編寫IE 8特殊版本。」
@Madhu Agrawal：「我最怕的是在只安裝了IE瀏覽器的Windows環境下進行開發工作……需要處理的問題太多了……」
受傷或者生病
編程其實並不是那種對體力要求很高的工作，但與其它大多數需要整天在電腦上敲擊的職位一樣，如果胳膊、手掌或者手指出了問題，工作也就很難順利進行了。此外，編程人員的視力與邏輯思考能力如果受到了影響，也會對日常工作造成嚴重不便。考慮到以上情況，典型的軟體開發人員自然也會在噩夢中遇到對應的狀況，即自己身體的某個或者某些部分不聽使喚、因而沒法完成開發任務。
@Aitjcize：「……我最怕的是手指割破了或者眼睛看不見了……那樣就沒法再寫代碼了。」
@Daniel Super：「我最怕自己的大腦出現了某種嚴重的病變，這樣我就沒辦法像原先那樣流暢地進行思考、但卻又保有自己聰明睿智時的相關記憶——簡直太痛苦了。」
@Matt Nicolls：「我最怕腕管綜合症、肘管綜合症以及其它任何可能讓自己沒法用手的病變。」
@Kelly Draper：「早上一覺醒來卻發現有人在夜裡把我的手指給偷走了。用胳膊肘打字真的很費勁。」
我在開發中遺留的漏洞造成危害甚至奪人性命
相信沒有哪位軟體開發人員希望自己打造的成果當中存在漏洞。當然，也不是所有漏洞都會帶來惡性後果——其中一些雖然有點討厭，但卻沒什麼危害。而有一些則有可能會給企業或者客戶造成經濟損失，甚至導致相關人士丟掉工作（例如需要為其負責的編程人員）。而程式設計師們最不想看到的就是，自己所構建的軟體方案在實際運行中給用戶帶來身體傷害甚至奪人性命。
@Kjetil Seim Haugen： 「我最怕的就是自己目前正在開發的天然氣鑽機控制系統出現問題……」
@Jeremy：「我最害怕的是自己軟體中的漏洞給其他人造成身體傷害。」
@Mark2008：「我能想到的最嚴重後果就是某人所編寫的交通指示燈程序沒能正常起效，由此導致的車禍則造成重大傷亡……又或者某些醫學掃描儀輻射量控制不當而致人死亡……包括某些軍事GPS系統錯誤地將飛行員指引到了敵方的空中火力覆蓋網之內……」
@Jon Kannegaard：「我最怕的是軟體漏洞奪人性格——這種情況之前確實發生過。」
段錯誤
開發人員的另一大常見噩夢是在運行中發現段錯誤。這類錯誤通常是由內在訪問衝突所造成，即程序試圖訪問受限內存或者執行受限操作。一般來講，這類情況下內存管理單元會向作業系統發出通知，而作業系統往往會反過來向相關進程發出通知並最終導致程序崩潰——而這無疑會令那些嘗試找到問題原因的開發人員們倍感頭痛。有鑑於此，難怪很多程式設計師最擔心的就是在自己的屏幕上看到這幾個字了。
@Samantray：「段錯誤是最最恐怖的噩夢！」 Supratim
@Zeina Shajahan：「除非運行調試工具，否則這類問題可能由上百種原因導致、而我們根本搞不清狀況。」
@Gomathi Sunder：「『段錯誤。代碼已轉儲。』當我們不小心使用了錯誤的指針並導致這類問題時，心中像是有無數羊駝奔騰而過。」
@Gaurav Jain：「任何錯誤都能由經驗豐富的程式設計師在幾分鐘之內修復完成，但段錯誤或者無用循環則不行……願程式設計師安息！」
