[譯] 虛構問題，低質量軟件的根源

• 原文地址：Imaginary problems, the root of bad software
• 原文做者：George
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：ssshooter

從使用的工具，到團隊內部的溝通質量，到開發人員的利益，以及你使用的測試方法，有許多因素能夠成爲低質量軟件的催化劑。

我認爲其中最主要的問題是，幾乎全部低質量軟件的根源：虛構問題。

複雜的軟件並不是設計之初就過於繁雜或功能失調。只是由於它在製做過程當中添油加醋，最終結果有別於初心。

播客應用

假設您是播客主持，想擁有本身的網站，能夠在其中銷售促銷產品，能夠不經第三方接廣告，最重要的是，向您的觀衆提供播客，視頻和博客文章。

你這個小小的網頁應用可能有以下要求：

• 北美地區能夠快速加載內容，播客直播與下載。
• 99.99% 的用戶在前 15 分鐘內不會遇到應用崩潰，固然，最好永遠不會發生。
• 與 Google AdWords 較好地集成，有時間的話再接入其餘廣告商。
• 動態連接到個人 Zazzle 上的最新產品，能夠的話，根據用戶觀看的劇集向用戶提供推薦。
• 由於我在 Facebook 作直播，因此要集成 Facebook 直播模塊。若是能夠本身作出一套直播系統，不依賴於 Facebook，那就更好了。

你把這些要求交給一個承包商，聊了一下。兩個月後，他們向你展現 MVP，你氣炸了，你以爲浪費了 15000 美圓在一件垃圾上，你只想把你的錢要回來。

看着這東西生氣是正常的，由於第一次打開它時屏幕像死機同樣。你問他如何修改網站上的廣告，他指了指那個又醜又讓人看不懂的自定義 UI。Zazzle 的商品連接有一半是破損或是缺乏圖像的，Facebook 直播流還有延遲！

但開發團隊對你的憤怒感到困惑，從他們的角度來看，他們已經爲你赴湯蹈火了。

他們全心全意編寫了這個應用，它有一些驚人的特性：

• 最早進的推薦系統。
• 轉播你的視頻或直播的算法（用於前面提到的推薦系統）。
• 世界各地可在 200ms 內加載你的首頁。
• 幾乎從頭開始構建流媒體協議和客戶端，你隨時能夠從 Facebook 直播切換過來。
• 可以讓你輕鬆集成 20 多個廣告平臺的服務。

問題來了，你須要的僅僅是核心功能，若是有餘力實現，才加入其餘特性。然而，開發團隊收到的需求可能大相徑庭了。開發團隊聽到了一些激動人心的挑戰……還有一些無聊的基本功能，他們不怎麼在乎。

最慘的是你沒有直接與開發者溝通，而是像在玩傳話遊戲同樣，跟一個銷售人員談過，銷售人員與中層管理人員會面，而後編寫了套業務規範並將它們交給了 PM，PM 編寫了一些技術規範並將它們交給了團隊負責人/架構師，負責人開始與他的團隊設計產品。每通過一層交接，需求均可能被扭曲。

這是一種應對機制

想象問題一般比實際問題更好玩。天才喜歡玩競技遊戲，構建和解決數學問題，甚至編寫試圖回答有關人類情況這種抽象問題的書籍，全部這些都是免費的。不過，通常程序員可能會向您收取至關數量的費用，爲你構建一個相對簡單的 Android 應用。這不是由於平庸的程序員比天才更難找到，只是由於前者作的事情都頗有趣，後者可能會比較無聊。

大多數程序員但願得到報酬並同時得到樂趣。可是，對大多數狀況下，這至關困難。固然，對於咱們大多數人來講，「樂趣」的定義是徹底不一樣的，但對於許多工程師來講，「樂趣」能夠歸結爲，可解決性範圍內，有趣並具備挑戰性的問題。

你給一個有點頭腦的人一堆不能自動化完成的無聊任務，他們早晚會被逼瘋。不過經歷了數十億年的進化，人類大腦在保持理智方面很是有才能。就像童年困難或虐待的受害者能夠在童話書中獲得解脫，企業編程或自由網絡開發的受害者能夠在解決虛構問題中獲得解脫。

軟件工程師爲本身創造虛構問題的數量，與他們的想象力和他們應該解決的實際問題的難度有關。

咱們應該意識到，這個問題並非開發人員所獨有的。管理，銷售，HR，顧問，法務甚至會計都有本身獨有的方式來創造虛構問題。當他們出席的會議內容不多涉及到本身的時候，他們主動讓本身更多地參與決策，過度強調與他們角色有關的問題（例如法務：咱們的狗狗日託 App 必須從上線第 1 天 101% 符合 GDPR，咱們不能成爲法律先例）。儘管沒有必要，他們仍是僱用了一整個團隊處理這個問題，這麼作顯得他們在這個項目中很重要，有作實事。

人是活的，問題是死的，因此聰明人總能找到一種應對方式。

傳話驅動式設計

虛構問題不只僅由於開發人員太無聊，也由於溝通鏈太長。

我偶爾會接一些外包。之前，外包客戶是不能本身挑的，這就意味着我甚至可能會在工做中遇到 DID（人格分裂）和 ADHD（多動症）病例。我曾收發了 100 多封郵件，僅僅是討論 MVP 裏微不足道的細節；曾遇到有人在一週內把項目中的每個需求都改了個遍的狀況；曾有客戶問過諸如「這能夠發行虛擬貨幣嗎？」或「咱們能夠在這裏加人工智能嗎？」等問題。

固然，大多數客戶仍是理智的，但他們每每由於缺少相關知識，沒法清晰表達他們的需求。但這沒問題，由於這是我做爲「計算機專業人員」工做的一部分，幫助人們根據他們的使用場景，判斷他們的軟件須要或不須要什麼。可是當你和客戶之間相隔數層，這件事便會變得十分困難。

大多數公司喜歡僱傭銷售人員安利潛在客戶，協商價格並概述這個價格能夠獲得什麼功能。還有另外一批善於交際的人與客戶討論更多深度要求和細節，其實他們也算是銷售人員，只是職位名稱不一樣。接着是內部領導層的意見，多級管理層以及技術團隊內部的層級結構。

需求經歷這麼多人，即便這些人的意見是好的，事情也會發生變化。有些會因其無心義而被改變，這些定義是愚蠢的，因此須要從新定義。銷售人員可能會說「只要多付 39999，咱們就能夠在區塊鏈上實現這個功能」……而後後面的人要思考「在區塊鏈實現這個功能」是什麼鬼意思。

因此一般需求變化的緣由有兩點，在多級傳遞中有人誤解了某些事情，或者有人使用上述應對機制來使他或團隊的工做更有趣和使人印象深入。

所以，最原始的需求，最迫切須要解決的問題，在各級傳達中丟失。並被虛構問題和一片空白所取代，接着，你們都用他們本身虛構問題填補這些空白，由於現有的問題真的很讓人乏味，他們一個應對方式即是填補這些空白。

過分複雜和天然選擇

一般狀況下，存在虛構問題更深層的緣由是，它們有助於團隊或公司的壯大，虛構問題成爲維持公司不可或缺的一部分。

People who are bred, selected and compensated to find complicated solutions do not have an incentive to implement simplified ones. — Taleb

你據說過僅靠三位工程師就能輕鬆地搭建網上銀行系統的狀況嗎？他們使用功能設計理論和內存安全語言，從頭開發了一些完美無瑕的銀行軟件，而後開始將大型銀行遷移到他們驚人的基礎設施。

可能沒聽過，由於根本不存在。甚至，還有成千上萬的團隊成千上萬的開發人員，連「回滾」這麼簡單的概念都不清楚，而偏偏是他們，在日復一日地編寫銀行軟件。

數字的存儲和傳輸的技術要求並不高。創建整個互聯網的索引，在 2 秒內提供問題搜索結果纔是一個難題，只有少數聰明人去千方百計解決這個問題。

問題在於銀行生態系統很是善於保持一種無人監管的狀態。這臺運行良好的機器保留了本身的斂財機制。它的領導者是掠奪於社會的腐敗者，但組織的領導者只是其成員的一個象徵。

個人意思不是在銀行工做的人都是壞人。相反，他們一般是很友善，致力於爲家人提升生活質量。但他們要的不是修復銀行軟件，而是保持就業。在如今的經濟環境中，丟了工做可不是開玩笑的。在銀行業中，話多，主動可讓你更有存在感。

因此銀行業這風氣，不是由於行之有效，而是已經產生了慣性。這種慣性以處理虛構問題的形式出現，以免解決實際問題。若是點明瞭的真正的問題，給其餘人的工做帶來威脅，可能會致使你被解僱，甚至像高盛這樣特別使人討厭的「機構」，給一些聯邦調查局官員寄了封信，而後毀掉你一輩子。

It is difficult to get a man to understand something, when his salary depends upon his not understanding it! — Upton Sinclair

企業最高管理層（C-suite）不會在乎他們的高層管理人員（upper management）將90％的時間花在「客戶會議」上，這些在熱帶島嶼舉辦的「會議」還花費了百萬美圓的「其餘費用」。由於高層管理人員對他們自己的腐敗視而不見。

高層管理人員不會在乎中層管理人員（middle managers）買下幾個古怪的辦公室，僱傭三名祕書和十幾名實習生。由於有了中層管理人員，他們能活在華爾街之狼的幻想中。

中層管理人員不會在乎直線經理（line managers）將時間花在怎麼修改「改進咱們的敏捷方法」的 PPT，而非下降成本。由於直線經理知足了他們對獨裁的幻想。

直線經理不會在乎技術團隊負責人和架構師滿口都是「下一代系統間的接口使用 JRPC 和 使用 Hibernate 和 Spring 的微服務」，而不是優化那成噸的 Mysql 查詢要查老半天。由於團隊負責人僞裝不知道他們的上司甚至連 Excel 都用很差，還幾周到辦公室一次。

團隊負責人不會在乎開發人員使用新的 JS 框架，一年改 10 次 UI，而不是檢查如下數據庫查詢爲何這麼慢。由於開發人員僞裝不知道他們的領隊根本沒寫代碼，最多也就畫個 DOT 圖。

這是一個解決虛構問題的惡性循環，從 CEO 僞裝不知道多賺三千萬也不能解決本身的家庭問題，到 UX 實習生僞裝不知道從新設計一個「提交按鈕」，他們的密碼仍是以明文傳輸。

可是每一個人都須要不斷解決虛構問題，由於一旦他們停下來關注真正的問題，他們可能會意識到整個系統的崩塌。他們可能會發現 Debra 已經坐在那個角落，盯着內部機房的監控圖表 10 年，儘管該公司 5 年前已經遷移到 AWS。他們可能會意識到他們 99% 的工做就是延續別人的工做……這個事實對絕大部分人都難以接受，因此我才說，他們必定會找到了一種應對方式。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。