30 年間,軟件開發行業為何 Bug 紛飛?

在時間的推移歷程中,軟件行業早已發生了天翻地覆的變化。和曾經大家習以為常的編碼日常相比,越多越多的開發者發現,如今“測試驅動開發,開發讓位測試”卻成為了一種常態,究竟是什麼導致了這樣 Bug 的出現?本文作者將從其自身三十年的軟件開發經驗出發,帶領我們共同探尋真相。

30 年间,软件开发行业为何 Bug 纷飞?

作者 | Chris Fox

我原本打算以第三人稱撰寫這篇文章,希望能夠客觀地描述三十年來我目睹的軟件開發行業的變化。然而,寫到一半我又改變了注意,所以我將在本文中講述個人的親身經歷,然後再簡單地分析一下哪些因素導致瞭如今的軟件開發世界裡出現了諸多荒謬和錯誤。

致年輕的開發者

許多人正值風華正茂,他們未曾見過軟件開發舊日的美好時光,所以他們也不理解我對以前美好的工作環境的無限懷念,他們不明白我們能夠在無人打擾的環境中工作是多麼至關重要。就像我的一些越南學生,十幾歲的他們沒有聽過甲殼蟲樂隊,也不明白我們為什麼會將這個樂隊視為珍寶,如果二三十歲的你們沒有見過軟件公司的員工頻繁被各種對話打斷,而無法長時間地集中精神工作的情景,那麼可能就無法想象那是一種怎樣的情形。我覺得你應該試著想象一下。

我想重新喚回人們的這種意識。我不關心敏捷、Scrum或極限編程,這些只是一時的狂熱,很愚蠢而且會干擾注意力,所以根本解決不了問題。我可以毫不誇張地說,微軟早期的傑出表現正是因為他們建立了不打斷他人注意力的企業文化,而這種傑出表現消失的直接原因也是因為他們放棄了這種意識。

本文參考了《Flow: The Psychology of Optimal Experience》,如果你希望瞭解學術的研究結果,那麼可以讀一讀這本書。

30 年间,软件开发行业为何 Bug 纷飞?

早年的經歷

我從1988年開始以編寫軟件為生。一年後,我去了微軟,我在單人辦公間工作,鮮有人打擾,但那是在微軟享有此殊榮的最後一年。回想那時的感覺真是太棒了:我們就像王子一樣,我們的工作效率之高也是空前絕後。公司圍繞《Flow》建立了一種文化,讓我們能夠進入並保持這種狀態,因為這正是我們最佳的工作方式。

《Flow》的偉大之處

雖然在我進入微軟前不久,他們就舉行了首次公開募股,但公司真正的變化始於1990年5月發佈的Windows 3.0。我們的工作環境在一夜之間發生了巨大變化:我開始和一個煙鬼共用一個辦公室,他整天大聲地打電話。與此同時,我們的會議也越來越多。

1989-2009年間,我一直在微軟工作,差不多一半時間是全職工作,一半時間是合同工,然而情況每況愈下,最後是Windows Vista項目。

偉大的墮落

我的人生從未如此疲憊,承受的壓力也從未如此之大,我們就像奴隸一樣,每週工作70個小時以上,然而,幸運的話也只能完成4-6個小時的實際工作。其他時間都在與代碼管理系統苦苦作鬥爭,那個系統裡到處充斥著尚未完成或質量低劣的功能。

2009年的時候,一切都陷入了混亂。人們對質量的熱愛完全被機械化的檢查框方法所取代,有幾次我都在絕境中掙扎。1989年的時候永遠不會發生這樣的事情,因為那時嚴謹才是最崇高的美德。我為Windows Media Player DRM準備的威脅模型有20頁之多,裡面寫滿了漏洞和緩解措施,但是他們要求只能有1-2頁,因為每個漏洞都需要經過審查然後解決掉。

卓越消失了、死了、被掩埋了。2008年底,我的經理要求我在應用程序外部編寫蹩腳的代碼,以方便他們在這些代碼上運行單元測試(目的只是為了證明該項目“有單元測試”),於是我決定跳槽。當他告訴我一個名叫“測試驅動開發”的新事物時,我決定更新自己的簡歷,然後離職。可惜我沒有立即付諸行動,沒想到後面還有更糟糕的事情。當他們讓我做結對編程的時候,我憤然離職了。

十年前:敏捷

我曾在西雅圖市中心的Real Networks工作。西雅圖的交通是個大問題,很多人的人生使命似乎就是造成堵塞交通。但是,由於我一般都在9:30離家,早高峰已經過去,路上只需要花費30分鐘,因此還算不錯。

後來,我們團隊開始嘗試一種名叫“敏捷”的新事物。對我而言,這意味著我必須參加“清晨站立會議”,會議在8:30舉行,因此我到達辦公室的時間需要提前90分鐘。這意味著我不得不在早高峰期上路,原本30分鐘的路程現在變成了90分鐘,每次我都會遲到而且感覺筋疲力盡。我問他們是否可以推遲會議。他們說,不行,這可是清晨站立會議啊。(可是,我們並沒有站起來啊)。

這個會議本身也極其荒謬。參加會議的每個開發人員幾乎都會說他正在繼續昨天的工作,偶爾也會提到開始了某個新工作,目前尚無進展。

項目經理的表現則更糟,他看上去總是生氣勃勃的樣子,聲音歡快而愉悅,聽起來他“參與了很多工作”,但實際上我知道大部分時間裡他們都在Facebook上玩遊戲。我經常聽他們提起“故事”,後來才意識到這不是指某款我們正在發售的遊戲。請問,“故事”究竟是什麼意思?

後來,我發現“故事”指的是我們所說的用戶場景、使用案例。我對敏捷的瞭解越深,我遇到的新名詞就越多,然而迄今為止,我還沒有看到太多的附加值。不過,還有更多會議。

我抗議“故事”。這個詞感覺很幼稚,就像強迫收銀員穿上可笑的服裝搞促銷活動或慶祝假期。他們告訴我,就像開會一樣,“故事”也是敏捷的一部分,我們需要遵守這些規則。然而,我感覺“Scrum”不過就是報告進度,為什麼我們不能像過去20年一樣通過郵件直接報告?

就因為這些無厘頭的原因,我就需要在上下班的路上多花一個小時(無償)。真是個無畏的新世界。

30 年间,软件开发行业为何 Bug 纷飞?

獨立工作

2010年,我去了越南兩次,去看我的新房子,第一次去的時候還在建,第二次在裡面住了三個星期。在我與Real的合同多次續約的過程中,有一半的同事都被解僱了,但最終我的合同也結束了,很長一段時間以來最愉快的一段工作結束了。我跟每個人相處得都很融洽,而且也取得了一些重大成就,公司裡唯一的一個混蛋沒有與我共事,而且在一次裁員中也被裁退了。

30 年间,软件开发行业为何 Bug 纷飞?

我在越南的家

我打算到2019年退休的時候就搬家。每次想到沉悶的白板面試和一系列高壓力的工作,我就渾身難受,我非常享受在美麗的新家的生活,所以我決定打包出發,2010年11月15日我離開了美國,打算在56歲的時候退休,彈彈吉他,看看物理書籍,在一個非常陌生的語言環境中生活,放鬆身心。

後來,我學會了說越南語,否則我會無聊。我是閒不住的人。

一位朋友建議我學習 iPhone 和 iPad 編程,這些工具都是免費的,而且我懷念編程。於是,我購買了MacBook,學習了iOS、Objective C 和 XCode,而且很快就構建了一款應用。我又一次回到了軟件開發的世界。

2011年-2016年間,我先是為自己,後來又為客戶編寫 iOS 和 MacOS 應用程序。這雖然很好,但我想賺更多錢,所以我找到了自由職業中介所。2017年,我獲得了在加利福尼亞的一家公司從事服務器端工作的機會。我學習了C#、實體框架和 ASP.NET,後來當初推薦了我的朋友離開了公司,於是我接管了服務器和數據庫。這份工作一直持續了30個月,是一段愉快的經歷,我掌握了一些最新的技術。我喜歡服務器和數據庫。

這期間內我一直是單獨工作。我是團隊的一員,我們的團隊成員包括:一位居住在悉尼的瀏覽器開發,還有身在越南的我。我們需要協作開發REST API,但我們兩個都是獨立工作的。

令人費解的當前世界

去年8月,那份工作結束了,我發現找遠程的工作很簡單,我的獨立性和承擔責任的意願都是優秀的品質。

然而,我發現軟件行業發生了翻天覆地的變化。

術語和時尚

“故事”僅僅是個開端。在我之前的工作中,有兩名開發主管在講話的時候喜歡使用一連串的術語。除了“工業標準”之類爭論時常用的詞語外,還有“技術債務”實際上只是“未完成的工作”的婉轉說法。“分支清理”的實際意思就是針對Git分支上積累的提交記錄做無用功。

如今,這個行業到處都充斥著術語。“敏捷”無處不在,意味著每個人都有不同的理解。“重構”也是如此,雖然我認為它只是“編輯”的同義詞。“衝刺”是一個小里程碑,帶有加班的含義,但也沒有任何新意。

原來我們會說用戶場景、未完成的工作和編輯,只要我還在這個行業裡,這些舊的術語對於我來說也挺好。小小的里程碑也沒有革命性。加班,就更加無需我多說了。

如果非要我參加“衝刺回顧會議”(“花4個小時來討論我們剛剛學到了哪些團隊合作知識”),我會發瘋。

除此之外,還有一堆的其他會議,毫無新意。

獨立而又自負

這是讓人不寒而慄的思想:雖然我可以獨自管理大型項目,但我算不上傑出的開發人員,我們是自負的“暴君”,我們的下場是被降職或解僱。這全都是為了團隊精神:一起工作,一起在上班時間玩遊戲,站在桌子上,高舉著酒杯為團隊鼓舞士氣,還有結對編程等等。

這簡直形同身於地獄的最深處。

奇怪的是,求職廣告似乎仍然偏愛那些可以獨立工作、不需要監督以及高度主動的開發人員。也許需要別人來告訴他們,這樣的開發人員都不好,他們應該僱傭可以像連體雙胞胎那樣工作的團隊。

Flow的盡頭

開放的辦公室實際上形同虛設;協作式編程意味著不斷與人交流,誰也別想舒服地坐著,本來這個過程的目的是代碼審查,但實際上卻完全不可能集中精力。持續不斷的交談,我們不能關上門保持沉默和集中注意力,戴著耳機就意味著你不配合團隊合作。

Flow創造了過去的輝煌,而它已離我們遠去,如今平庸卻成了可達到的最高標準。

開發讓位於測試

這可能是軟件開發界最怪異的變化。

誠然,過去我們沒有認真對待測試。微軟經常開玩笑說,大家都不應該使用版本號為偶數的軟件,因為這些軟件在等著用戶報告錯誤。請勿使用2.0版,因為2.1版將修復客戶報告的所有錯誤,至少會修復值得修復的bug。

我笑不出來。

我認為如今受“測試驅動開發”這一荒謬方法論的刺激,我們表現出了過激的反應。

測試驅動開發是這個錯誤的根本。

很多網上的討論都說,軟件中沒有什麼比單元測試更重要的工作了,單元測試比它們比可交付成果本身更重要,文檔已經過時,單元測試就是設計文檔,單元測試定義了API;根據完整的設計編寫測試太不夠格,在實現前根據猜測編寫測試才是時尚;不足100%的覆蓋率就是翫忽職守,100%的覆蓋率才是榮耀,開發人員應該全權負責測試他們產品,我們不需要黑盒測試,也不需要找別人再看一眼。

這些態度的偏執根本不需要我來指出。

任何一個有經驗的人都能看出最後一個的荒謬。我們每個人都有盲點,我們會忽略某種情況,我們肯定會在編寫測試和在編寫代碼的時候漏掉某些情況。這是人之常情,並不難理解。

30 年间,软件开发行业为何 Bug 纷飞?

再也不去上班

我喜歡編寫軟件。我喜歡解決問題和開發功能。自從1984年編寫了一個GW-BASIC程序來生成質數列表以來,我一直都很喜歡編程;自從1967年我用COMPASS彙編語言編寫程序以來,我就一直喜歡編程。而這個愛好如今成為了我的職業。

然而,如今這個時代瘋了。我無法在開放式的辦公室裡工作,我受不了周圍的人滿口專業術語,同時還需要應付強制性的合規,還有沒完沒了的會議以及對獨自工作的人的嘲笑。我希望這個行業能夠回到1990年,重視並鼓勵人們集中精力工作。

我喜歡服務開發的工作,並希望可以再次找到這類的工作。但是,我不會考慮那些喜歡採用結對編程和非要拽新名詞的職位。

我想嘗試技術領域的寫作,如今我有一份新工作,為日本的一家公司工作,略微寬慰我在越南家中的孤寂。同時,我還會學習遠程辦公所需的新技能,並希望在我能承受的環境中找到更多有關服務器和數據庫的開發工作。

一個看起來並不瘋狂的環境。

原文:https://hackernoon.com/what-happened-to-software-development-j92032w9

本文為 CSDN 翻譯,轉載請註明來源出處。

【End】


分享到:


相關文章: