主持人 > 博客 > 網絡新聞 > 我程式設計生涯中最尷尬的錯誤（迄今為止）

我程式設計生涯中最尷尬的錯誤（迄今為止）

我程式設計生涯中最尷尬的錯誤（迄今為止）
正如他們所說，如果你不為自己的舊程式碼感到羞恥，那麼你就沒有成長為一名程式設計師——我同意這個觀點。 我 40 多年前開始編程只是為了好玩，30 年前才開始專業編程，所以我犯了很多錯誤。 非常。 身為一名電腦科學教授，我教導我的學生從錯誤中學習——他們的、我的和其他人的錯誤。 我想是時候談談我的錯誤了，以免失去謙虛。 我希望它們對某人有用。

第三名－微軟C編譯器

我的學校老師認為，《羅密歐與茱麗葉》不能被視為悲劇，因為劇中人物沒有悲劇性的罪惡感——他們只是表現得愚蠢，就像青少年應該做的那樣。 當時我並不同意他的觀點，但現在我看到了他的觀點有一定道理，尤其是在程式設計方面。

當我在麻省理工學院讀完大二時，我還很年輕，在生活和程式設計方面都缺乏經驗。 夏天的時候，我在微軟的C 編譯器團隊實習，一開始我做一些常規的事情，比如分析支持，然後我被委託從事編譯器中最有趣的部分（正如我所想的）——後端最佳化. 特別是，我必須改進分支語句的 x86 程式碼。

決心為每種可能的情況編寫最佳的機器代碼，我一頭扎進了泳池。 如果值的分佈密度很高，我將它們輸入 轉換表。 如果它們有一個公約數，我用它來使表格更緊（但前提是可以使用除法來完成） 位移位）。 當所有的值都是XNUMX的冪時，我又做了一次最佳化。 如果一組值不滿足我的條件，我就把它分成幾個可最佳化的情況，並使用已經最佳化過的程式碼。

這是一場惡夢。 許多年後我被告知繼承我程式碼的程式設計師討厭我。

我程式設計生涯中最尷尬的錯誤（迄今為止）

學過的知識

正如 David Patterson 和 John Hennessy 在《電腦體系結構和電腦系統設計》中所寫的那樣，體系結構和設計的主要原則之一通常會讓事情盡快運作。

加速常見情況比優化罕見情況更有效地提高效能。 諷刺的是，常見案例往往比罕見案例更簡單。 這個邏輯建議假設您知道哪種情況被認為是常見的 - 這只有透過仔細的測試和測量過程才能實現。

在我的辯護中，我試圖弄清楚分支語句在實踐中是什麼樣子的（例如有多少分支以及常量如何分佈），但在 1988 年，這些資訊不可用。 但是，每當當前編譯器無法為我提出的人工範例產生最佳程式碼時，我就不應該添加特殊情況。

我需要打電話給一位經驗豐富的開發人員，與他一起思考常見情況並具體處理。 我會編寫更少的程式碼，但這是一件好事。 正如 Stack Overflow 創始人 Jeff Atwood 所寫，程式設計師最大的敵人是程式設計師自己：

我知道你有最好的意圖，我們也是。 我們創建程式並且喜歡編寫程式碼。 我們就是這樣被造的。 我們認為任何問題都可以透過膠帶、自製拐杖和一些代碼來解決。 儘管程式設計師承認這一點很痛苦，但最好的程式碼就是不存在的程式碼。 每條新線路都需要調試和支持，需要被理解。 當您添加新程式碼時，您應該不情願和厭惡地這樣做，因為所有其他選項都已用盡。 許多程式設計師編寫了太多程式碼，使其成為我們的敵人。

如果我編寫了涵蓋常見情況的更簡單的程式碼，那麼在必要時更新會更容易。 我留下了一堆沒人願意處理的爛攤子。

我程式設計生涯中最尷尬的錯誤（迄今為止）

第二名：社群網路廣告

當我在 Google 從事社群媒體廣告工作時（還記得 Myspace 嗎？），我用 C++ 寫了這樣的東西：

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

程式設計師可能會立即看到錯誤：最後一個參數應該是 j，而不是 i。 單元測試沒有發現錯誤，我的審閱者也沒有發現錯誤。 發射進行了，一天晚上我的程式碼到達伺服器並導致資料中心的所有電腦崩潰。

沒有什麼不好的事情發生。 任何人都不會受到任何影響，因為在全球發布之前，程式碼已在一個資料中心內進行了測試。 除非SRE工程師暫時停止打撞球，做一點回滾。 第二天早上，我收到了一封包含故障轉儲的電子郵件，更正了程式碼並添加了可以捕獲錯誤的單元測試。 由於我遵循了協議 - 否則我的程式碼將無法運行 - 沒有其他問題。

我程式設計生涯中最尷尬的錯誤（迄今為止）

學過的知識

許多人確信，如此重大的錯誤肯定會導致罪魁禍首被解僱，但事實並非如此：首先，所有程式設計師都會犯錯誤，其次，他們很少會犯兩次同樣的錯誤。

事實上，我有一個程式設計師朋友，他是一位出色的工程師，卻因為犯了一個錯誤而被解僱。 之後，他被谷歌錄用（很快就升職了）——他在面試中誠實地講述了自己所犯的錯誤，這並不被認為是致命的。

這是什麼 告訴 關於 IBM 傳奇掌門人 Thomas Watson：

一項價值約一百萬美元的政府訂單被宣布。 IBM 公司——或者更確切地說，老托馬斯·沃森本人——真的很想得到它。 不幸的是，銷售代表無法做到這一點，IBM 失去了投標。 第二天，這名員工來到沃森先生的辦公室，將一個信封放在他的辦公桌上。 沃森先生甚至懶得看它——他正在等一位員工，他知道這是一封辭職信。

沃森問了什麼問題。

銷售代表詳細介紹了招標的進展。 他列舉了一些本來可以避免的錯誤。 最後，他說：「沃森先生，謝謝你讓我解釋。 我知道我們多麼需要這份訂單。 我知道他有多重要。」然後準備離開。

沃森走到門口，看著他的眼睛，把信封還給他，上面寫著：「我怎麼能讓你走？ 我剛剛在你的教育上投資了一百萬美元。

我有一件T卹，上面寫著：“如果你真的從錯誤中學習，那麼我已經是大師了。” 事實上，說到錯誤，我是科學博士。

第一名：App Inventor API

真正可怕的錯誤會影響大量用戶，成為公眾知識，需要很長時間才能糾正，並且是由那些本來不可能犯下這些錯誤的人犯下的。 我最大的錯誤符合所有這些標準。

越差越好

我讀 理查德·加布里埃爾的文章 作為一名研究生，我在九十年代談到了這種方法，我非常喜歡它，所以我向我的學生詢問。 如果記不太清楚，刷新一下記憶，很小的。 本文在許多方面（包括簡單性）對「做對」的願望和「越壞越好」的方法進行了對比。

應該如何：設計的實作和介面應該簡單。 介面的簡單性比實現的簡單性更重要。

越差越好：設計在實作和介面上應該簡單。 實現的簡單性比介面的簡單性更重要。

讓我們暫時忘記這一點。 不幸的是，我已經忘記了很多年了。

應用發明家

在 Google 工作期間，我是團隊的一員 應用發明家，一個為有抱負的 Android 開發人員提供的拖放式線上開發環境。 那是 2009 年，我們急於及時發布 alpha 版本，以便在夏季為秋季教學時可以使用該環境的教師舉辦大師班。 我自願實現精靈，懷念我以前在 TI-99/4 上編寫遊戲的方式。 對於那些不知道的人來說，精靈是一種二維圖形對象，可以移動並與其他軟體元素互動。 精靈的例子包括太空船、小行星、彈珠和球拍。

我們用 Java 實作了物件導向的 App Inventor，所以裡面只有一堆物件。 由於球和精靈的行為非常相似，因此我創建了一個具有屬性（字段）X、Y、速度（速度）和標題（方向）的抽象精靈類別。 他們有相同的方法來偵測碰撞、從螢幕邊緣反彈等。

球和精靈之間的主要區別在於所繪製的內容是實心圓還是光柵。 由於我首先實作了精靈，因此指定影像所在位置左上角的 x 和 y 座標是合乎邏輯的。

我程式設計生涯中最尷尬的錯誤（迄今為止）
一旦精靈開始工作，我決定可以用很少的程式碼來實現球物件。 唯一的問題是我採取了最簡單的路線（從實現者的角度來看），指示球輪廓左上角的 x 和 y 座標。

我程式設計生涯中最尷尬的錯誤（迄今為止）
事實上，有必要指出圓心的 x 和 y 座標，正如任何數學教科書和任何其他提到圓的資料中所教導的那樣。

我程式設計生涯中最尷尬的錯誤（迄今為止）
與我過去的錯誤不同，這次不僅影響了我的同事，也影響了數百萬 App Inventor 用戶。 他們中的許多人都是孩子或完全是程式新手。 在處理每個存在球的應用程式時，他們必須執行許多不必要的步驟。 如果說我以前犯過的其他錯誤我都能笑著回憶起來，那麼這個錯誤至今仍讓我汗流浹背。

直到最近，也就是十年後，我才終於修復了這個錯誤。 “修補”，而不是“修復”，因為正如 Joshua Bloch 所說，API 是永恆的。 由於無法進行影響現有程式的更改，我們新增了 OriginAtCenter 屬性，其值在舊程式中為 false，在所有未來程式中為 true。 使用者可能會問一個邏輯問題：誰會想到將起點放在中心以外的地方。 給誰？ 對於十年前一位懶得創建普通 API 的程式設計師來說。

得到教訓

在處理 API 時（幾乎每個程式設計師有時都必須這樣做），您應該遵循 Joshua Bloch 的影片中概述的最佳建議“如何創建良好的 API 及其為何如此重要“或 在這個簡短的名單中:

  • 一個API既可以帶給你很大的好處，也可以帶給你很大的傷害。。 良好的 API 可以創造回頭客。 壞的會成為你永恆的惡夢。
  • 公共API就像鑽石一樣恆久遠。 全力以赴：再也沒有機會把每件事都做好。
  • API 概要應該簡短 — 一頁包含類別和方法簽名和描述，最多只佔一行。 如果第一次結果不完美，這將使您能夠輕鬆地重構 API。
  • 描述用例在實作 API 甚至制定其規格之前。 這樣您就可以避免實作和指定完全非功能性的 API。

如果我用人工腳本寫了哪怕一個簡短的概要，我很可能會發現錯誤並糾正它。 如果沒有，那麼我的一位同事一定會這麼做。 任何具有深遠影響的決定都需要考慮至少一天（這不僅適用於程式設計）。

理查德·加布里埃爾(Richard Gabriel) 文章的標題「更糟就是更好」指的是率先進入市場的優勢——即使產品不完美——而其他人則花費永恆的時間去追逐完美的產品。 反思精靈程式碼，我意識到我甚至不需要編寫更多程式碼來使其正確。 不管有人怎麼說，我都大錯特錯了。

結論

程式設計師每天都會犯錯誤，無論是編寫有錯誤的程式碼還是不想嘗試一些可以提高他們的技能和生產力的東西。 當然，你可以成為一名程式設計師，而不會犯下像我這樣嚴重的錯誤。 但如果不認識到自己的錯誤並從中學習，就不可能成為一個優秀的程式設計師。

我經常遇到一些學生，他們覺得自己犯了太多錯誤，因此不適合程式設計。 我知道冒充者症候群在 IT 領域是多麼普遍。 我希望你能學到我列出的教訓 - 但請記住主要的一個：我們每個人都會犯錯 - 令人尷尬的、有趣的、可怕的。 如果將來我沒有足夠的資料來繼續這篇文章，我會感到驚訝和不安。

來源： www.habr.com

添加評論