# 吉多·範羅蘇姆：Python 與程式設計的未來 > Python 之父回顧這門語言的設計初衷，並討論程式語言與開發者工具的未來走向。 - 原標題：#341 – Guido van Rossum: Python and the Future of Programming - 期數：第 341 期 - 釋出日期：2022-11-26 - 嘉賓 / 主題：吉多·範羅蘇姆 - 網頁版：https://lex.qiaomu.ai/tw/ep/guido-van-rossum-2/ - 官方頁面：https://lexfridman.com/guido-van-rossum-2/ - 精讀字數：約 9060 字（閱讀約 20 分鐘） > 本文為 lex.qiaomu.ai 基於原始訪談的 AI 改寫中文精讀，非官方翻譯；引用請註明出處並連結網頁版。 Python 3.11 釋出前夕，CPython 團隊給出的承諾是新版本比上一版快 10% 到 60%。一門三十多年前動筆的語言，靠改自己的底層實現拿到這個量級的提速，這份成績單放在任何工程領域都算漂亮。 Lex Fridman 問吉多·範羅蘇姆（Guido van Rossum）：這是怎麼做到的。 他沒接這個問題，先糾正了問題裡的一個詞。 > "CPython 是最後一個還站著的 Python 實現，也是歷史上第一個，我三十多年前親手寫的那個。"（吉多·範羅蘇姆） "最後一個還站著的"，這句話說得很輕。一門程式語言通常可以有多個實現，Jython 跑在 Java 虛擬機器上，IronPython 跑在 .NET 上，PyPy 用 Python 自己寫自己。這些名字前面都得掛個字首，因為不加字首就不知道你在說誰。只有 CPython 不需要，它就是 Python 本身。 名字裡的 C 是它用 C 語言寫成。一門語言的預設實現，是用另一門語言寫的程式。這件事在外行眼裡很反常，在程式設計師眼裡是常識，而這期節目的聽眾裡，這兩種人都有。 ## 一條船上坐著兩個人，其中一個只會釣魚 Lex 把聽眾劈成了兩類。一類是在船上釣魚、從沒聽說過程式設計的人，另一類是寫遍 C、C++、Python、Rust、Java，能把程式語言發展史倒背如流的矽谷頂級工程師。一條船，兩個人，中間隔著整個電腦科學。 吉多選了先讓釣魚那位滿意。 > "在海上，他顯然是更有用的那個人。你得讓他高興。"（吉多·範羅蘇姆） 怎麼跟他講？他手裡一定有個手機，所以他對手機裡發生的事情大概抱有懷疑。但他至少聽說過手機裡有一塊小小的計算機，而程式語言就是告訴這塊計算機該幹什麼的程式碼。再往下就別講了：零和一，彙編，暫存器。講這些等於在討論人類語言的時候去研究聲道、舌位和氣流。語言學討論"我愛你"這三個字的意思，不討論你的舌尖抵在上齒背還是下齒背。 Lex 在這裡插了一段自己的觀察。他說中文母語者講英語時常常分不清 L 和 R，他有個從沒找語言學家驗證過的猜想：漢語裡這兩個音本來就沒有對立，而不同地區的人在發那個中間音時，有的聽起來像 L，有的聽起來像 R。吉多順著往下接：斯拉夫語系裡有個 j 音，英語母語者發起來很彆扭。兩個人聊了幾句發音，然後一起把這個話題放下了。 放下得對。再往下就是舌頭怎麼擺了，而舌頭怎麼擺，和程式語言是什麼，中間隔著好幾層抽象。 ## 程式語言是一份菜譜，但要餵給兩個讀者 吉多給出的定義是：**程式語言就是一份菜譜，一行行告訴你該怎麼做出某樣東西。** 買一條麵包，切片，取兩片，一片抹芥末，一片抹果醬，然後放肉，再放乳酪。你要把這件事說得足夠清楚，清楚到沒有任何一種理解方式會出錯。 Lex 說他見過科學老師玩這個遊戲：讓學生寫下做三明治的步驟，老師嚴格照著做，做到學生抓狂為止。學生的意思是"拿兩片面包"，老師就真的把整袋麵包都拿過來。 這個遊戲暴露的正是自然語言和程式語言的根本差別。**在人類口語裡，歧義是特性，不是缺陷。**它是人與人之間那場舞蹈的一部分，你說一半，我猜一半，猜錯了笑一下，再補一句。律師喜歡歧義，因為歧義就是訴訟費。日常對話裡歧義也會帶來麻煩，但人們繞著走，靠上下文把它填平。 對著一個你愛的人說"我愛你"，對方不會試著編譯這句話然後報錯：請定義"love"。 > "不會。不過我猜我太太和我兒子聽到這三個字，理解會非常不一樣。"（吉多·範羅蘇姆） 同樣三個詞，同一個句子，兩個聽眾，兩種含義。靠的還是上下文。換成律師，他會追問你二十個問題。 程式語言乾的事，就是把這個上下文抽掉，把一份菜譜寫成不管誰來讀都只能讀出一種意思的東西。 ## 《Python 之禪》裡那句"可讀性很重要"是說給誰聽的 Lex 提到那份被無數 Python 開發者當口訣背的東西，《Python 之禪》。裡面有一句：可讀性很重要（Readability counts）。 這句話初看很怪。程式碼是給機器看的，機器不在乎你縮排幾個空格，你在中間插一行髒話它照樣跑。可讀性是給誰的？ 吉多的回答把整件事翻了個面。**軟體開發從四十年代末開始，就一直是件社交活動。**那個坐在實驗室裡獨自寫出天才程式碼的瘋狂科學家，其實並不存在。就算真的存在，他打字的速度也快不到哪去，等到他寫完最後一行，前面那幾十行寫了什麼，他自己也記不清了。 所以寫程式碼的時候，你同時在跟兩個物件說話。 一本菜譜只有一個讀者。作者寫一次，印十萬份，十萬人照著做櫻桃派。作者的全部目標是讓廚房裡那位業餘廚師看懂。軟體這個行當完全不同。軟體太複雜，複雜到你不可能一次寫對，所以必然有除錯，必然有修改，必然有別人接手，也必然有一年之後的你自己回來看這段程式碼。 兩個讀者，兩套要求，還經常打架。這就是為什麼"程式碼風格"這種東西在別的行業聽起來像個笑話，在軟體行業卻值得寫進語言的核心文件。 ## 除錯是三個完全不同的東西，被同一個詞裝在一起 Lex 讓吉多給除錯下個定義。那個回答被切成了三層。 最淺一層是蠢錯誤。少打一個字母，括號沒配對，路徑寫錯。 中間一層是邏輯錯誤。程式完全按你寫的跑了，跑出來的東西是錯的，因為你想錯了。 最深一層是這玩意壓根沒用。程式碼沒錯，邏輯沒錯，跑得又穩又快，只是它解決的問題不該被解決，或者解決的方式讓產品變得沒法用。 還有第四層，吉多專門拎出來說：**程式 99% 的時間表現完美，然後在某個邊緣情況上突然發瘋。這是今天幾乎所有軟體的真實狀態。**好軟體是這樣，差軟體那個 99% 會掉到 90% 甚至更低。 這句話往下推，得出的結論不太舒服。你今天用的每一個軟體，包括那些支撐銀行、醫院和電網的系統，都有若干條路徑是你從來沒走過、也永遠不會被走到的。軟體工程的成熟，相當程度上是學會了在這些路徑上放護欄，而不是假裝它們不存在。 ## 四個空格是怎麼來的 看 Python 程式碼的第一眼，看到的往往是形狀。左邊那道階梯，一層往裡縮一點，像一份排版講究的商務文件。 吉多的解釋很樸素。任何文字的可讀性都靠空間，把一份菜譜的所有專案符號刪掉，句子揉成一整塊，你在廚房裡連"哪些是原料、哪些是步驟、這一步到哪結束"都分不出來。縮排就是給程式碼造出這種可見的分組：一段文字裡套一段更小的文字，再套一段更小的。 問題在於縮排多少。縮排太深，三層之後螢幕上就沒地方放字了。縮排太淺，一眼看不出這是第一層還是第二層。 答案是四。理由是古代排版慣例，加上八十年代那批顯示器的典型寬度，兩個約束一夾，四個空格落在中間。這是個妥協，談不上定理。 Google 的 Python 程式碼風格指南用的是兩個空格，據說 Google 的 C++ 程式碼也是。你不習慣的話，讀起來會有點吃力，因為這種語言裡，高層結構完全由縮排決定，縮排淺了，骨架就模糊了。經典 Unix 那邊更誇張，一個 tab 八格，吉多覺得那看著彆扭，三層之後就貼到螢幕右邊了。 Python 的特殊之處在於，**縮排在這裡屬於語法的一部分，風格建議這個說法太輕了。**別的語言裡，C、Rust、C++、Java，你把程式碼寫成一整行，編譯器照樣給你編出來，只是同事會想打你。所以現實裡 IDE 會自動幫你縮排，縮錯了還會用紅波浪線吼你。人類用工具把一條軟規範硬成了事實標準，Python 只是把這條已經存在的規矩寫進了語言定義。 ## 花括號本來有可能出現在 Python 裡 Lex 問了個歷史問題：有沒有那麼一個平行宇宙，Python 是用花括號分塊的？ "絕對有。" 吉多說，很長一段時間裡他都確信縮排更好。就算把上下文全部抽掉，單看這個設計，他還是認為縮排更好，因為它減少了視覺噪音。 可惜上下文幾乎就是一切。而程式設計這件事的上下文是：**大多數程式設計師都熟悉好幾門語言，哪怕只精通一兩門。**除了 Python，可能再加上 Fortran，其他所有主流語言，Java、Rust、C++、JavaScript、TypeScript、Perl，全用花括號標記程式碼塊。Python 是那個異類。 異類是有代價的。一個從 Java 轉過來的人，第一天寫 Python 會覺得少了點什麼，像走路時突然發現自己一直在無意識地甩手。 那為什麼不改？ > "Python 裡沒有這個可能性。花括號在 Python 裡已經用來幹別的了，主要是字典。真要想換，會惹出一堆麻煩。"（吉多·範羅蘇姆） 他還補了一句更根本的：你不能重新定義 C 讓它是用縮排的，哪怕你打心底認為縮排更好。一門語言裡，這種級別的東西改不動。比這細小得多的細節，想達成一致都已經夠難了。Python 歷史上真為 tab 和空格打過一場大仗，為四個空格還是兩個還是八個吵過，最後的產物是一份推薦標準，外加一堆給不聽話的人準備的選項。 ## 時間旅行回去，他還是會選縮排 Lex 不放過他，把假設推到底：如果能穿回三十多年前，相容性完全不成問題，Python 從頭再來一遍，你還會選縮排嗎？ 會。理由有三條。 第一，它省下一對括號。而**這世界上配對的東西永遠不夠用**，省下來的括號可以拿去幹別的（在 Python 裡，它們後來確實去幹別的了）。 第二，對完全沒學過程式設計的人更友好。一門十三週的入門課，要把演算法、資料結構、語法、變數、迴圈、函式、遞迴、類、表示式、運算子全塞進去。能少講一個概念，就少一個讓人分心的東西。分號是教學裡最經典的麻煩：編譯器每次都抱怨我分號放錯了地方，或者我又忘了寫分號。Python 沒有分號，你忘不了它，也不會把它放到不該放的位置，因為你從一開始就沒學過它。 第三，也是吉多自己補的反面：**強制嚴格，本身就是在教東西。**它告訴新手，程式設計是一件在意細節的事，你不能像寫英語作文那樣隨便寫。當然，新手要操心的細節還有很多，這條資訊總能傳達到。 ## 美元符號是一塊記憶體不夠用的化石 Lex 換了個靶子：PHP 裡變數前面那個美元符號。他說這玩意在他的理解裡完全講不通，而且打字累，還特別容易錯。 吉多給了一段考古式的回答，講的是 Unix shell 的來歷。 最早的 shell 根本沒有"給指令碼傳引數"這個概念。一個指令碼就是幾行文字，每行是一條命令，一個非常原始的命令處理器讀它，把行首那個詞當作程式名，剩下的一整行當作文字丟給程式自己去解析成引數。 後來人們想要變數了，尤其是想要引數。麻煩來了。你寫下 program x y，這在原來的語義裡已經有確定含義：x 是一個檔名。可你想說的是"x 是一個變數，它的值才是檔名"。這兩件事必須能區分開。 而在五六十年代，寫這個指令碼直譯器的程式本身是個極小的程式，得塞進很小的一塊記憶體。最省事的做法是：逐字元掃描，看到某個特殊符號就跳到另一段程式碼，把後面一直到空格的東西讀出來當變數名。選哪個符號？美元符號便宜、顯眼、不容易和正常文字撞車。 它同時也是給人類讀者看的。二十行之後你看到 xyz 前面掛著一個美元符號，立刻知道 xyz 是指令碼的引數之一，硬碟上某個檔名這個身份被排除掉了。 PHP、Perl 都繼承了這條血脈。IBM 更早的作業控制語言裡也有類似的東西。這些設計活到了今天，活在支撐整個網際網路後端的程式碼裡。Wikipedia 裡就有一大堆 PHP。 > "這就像生物系統。DNA 的內部機制已經穩定了幾億年，裡面全是各種古怪的遺留物。如果你從零設計一個能自我複製的分子系統，絕不會那麼幹。"（吉多·範羅蘇姆） Lex 順著這個比喻往下說：生物系統有很多奇怪的冗餘，會以奇怪的方式出錯，但在有機體這個層面上依然有韌性。程式碼沒有這種韌性。 吉多不同意。他說你會驚訝於現代程式碼有多強的韌性。**哪怕是測試得很充分、實際執行良好的程式碼，裡面也有很多地方是壞的，只是錯誤被一層層機制吸收掉了，包括最後那一層：使用者。**使用者被告知重啟電腦，重啟一下，問題就消失了。溫和一點的版本是重新整理頁面，所有人遇到怪事都會下意識刷兩三次，然後才承認這裡真有問題。 Lex 說這個習慣得改，因為刷第二次通常只是把燈又關上了。吉多說，那就刷三次，這才是正確的教訓。 ## 一千行程式碼裡到底有幾個 bug Lex 丟擲一個想法：如果把執行核武器的程式碼、執行 Twitter、Facebook、Dropbox、Google、Windows 的程式碼，按每千行的 bug 數排成一張表，人們會不會被嚇到。 吉多說這取決於你讀沒讀過這個領域的研究。他記得上世紀八九十年代有過一批研究，覆蓋了各種軟體、各種語言、各種公司、各種開發風格，結論相當穩定：**在成熟的、被公認為質量很好的軟體裡，大約是每千行一個 bug。這已經是行業天花板。** Lex 隨即擺出一份資料，來自一家做程式設計分析的公司，視角是開發者端：平均每個開發者每一千行程式碼寫出 70 個 bug，其中 15 個會流到客戶手裡；修一個 bug 花的時間是寫一行程式碼的 30 倍；開發者 75% 的時間花在除錯上；美國一年在找 bug 和修 bug 上燒掉 1130 億美元。 吉多的第一反應是承認自己錯了一個數量級。 緊接著他做了那個關鍵的區分。**每千行一個 bug，說的是經過長期測試、已經穩定下來的成熟軟體。每千行 70 個，說的是你剛開始敲鍵盤的時候。**這兩個數字根本不測量同一件事。拿它們放在一張圖裡比較，就像拿新生兒的哭鬧次數和成年人的說話次數做對比，然後得出人類越活越沉默的結論。 他也順手把這頁資料看穿了：這是一家賣工具的公司做的內容。頁面底部必然掛著一個"聯絡我們"按鈕，潛臺詞是，你只要掏出比一千一百三十億少一點的錢，我們就幫你把這個坑填上。 Lex 提到 Stack Overflow 上有一份同主題的報告，他想開啟對照一下，頁面顯示"網站維護中"。 > "這挺諷刺的。"（吉多·範羅蘇姆） 一個支撐了全世界最大問答社群的技術，在你想引用它的資料時告訴你它掛了。軟體這東西的可靠性，大概就是這麼回事。 ## 你不可能在一年前就寫好今天的釋出計劃 吉多接著解釋那個 70 和 1 之間的落差從哪來。軟體開發是極度迭代的。**沒有人真的會做一份"一年後釋出什麼"的完整計劃，然後把細節全部敲定。**因為那些細節本身拼起來就是一份程式，而只要它是一份程式，你的計劃裡就也會有 bug，也會有想錯的地方。 所以你實際乾的事是這樣的：敲一堆程式碼，跑一下，看看它是不是你想的那個樣子，不對就改，改完再跑。幾十輪之後，剩下的那些錯誤，才輪得到"每千行一個"這個數字去描述。 Lex 在這裡承認，那個 70 出現的時候他也嚇了一跳。吉多的反應更平靜：這個數字說明的是一件事情，程式碼在誕生階段極其髒，髒到沒法看，而工程的全部工作就是把這份髒慢慢洗乾淨。 ## 他打字只用兩根手指，而且不打算改 話題拐到了打字上。吉多說自己是個很糟的打字員，十個手指都在用，但用得很差。他從沒上過打字課，也從沒專門去糾正這件事。**第一次認真學 QWERTY 鍵盤的佈局，是大學裡第一門程式設計課，那時候用的是打孔卡。**他就用兩根手指，一個鍵一個鍵地把程式碼戳出來。 Lex 說他有個觀察方法：讓任何一個程式設計師現場演示幾行程式碼，你就盯著他按退格鍵的次數。有人會為了改行首的一個錯字，往回退二十、三十、四十個字元，然後重新敲。熟練一點的會用方向鍵，或者動滑鼠，但滑鼠通常比方向鍵慢。很多人敲一個二十個字元長的單詞，敲到一半發現開頭錯了，就把整個詞退掉重來，有時候要重來三四次才對。 吉多在這裡做了一個區分，這個區分挺重要。**打錯一個字然後立刻改掉，嚴格說不算 bug。**但你確實為此浪費了時間，而且偶爾會有一個錯字漏網。等你又往下敲了十行，你不知道那十行裡哪一處有問題，只知道某處有問題。 這跟忘記初始化一個變數屬於兩個層面的問題。前者跑一遍就暴露了。後者在 Python 裡也跑一遍就暴露了，現代編譯器大多也能提前抓出來。真正麻煩的是第三種：變數你初始化了，名字也叫對了，但初始化的是另一個東西，或者你本意用的那個變數跟它重名了。這種東西編譯器抓不到，測試也不一定覆蓋得到，它會在某個深夜的線上環境裡冒出來。 ## 把退格鍵挪到拇指下面，是一個價值三十年的決定 Lex 順勢講了自己為什麼用 Kinesis 鍵盤：那種鍵盤把退格鍵放在拇指正下方。普通鍵盤的退格鍵在右手小指夠得著的地方，每按一次你的整隻手都要往外撐一下。很多人一輩子都在承受這個設計帶來的疼痛，只是沒意識到。 吉多問他，如果你在別人那兒，手邊只有標準鍵盤怎麼辦。 Lex 的回答很實在：你可以一輩子隨身帶著鍵盤。他在飛機上要寫程式碼或者大量打字的時候，會把筆記本攤開，再從包裡掏出一把 Kinesis 擺在旁邊。 > "我已經接受了自己是個怪人這件事。"（吉多·範羅蘇姆） 這句話往下接的是一段更普遍的經驗：很多人都有自己的一套舒適區配置，某些特定的設定能把生產力拉滿。有人看電影要蓋一條特定的毯子，他要的是那把鍵盤。它帶他進入一個能專注的狀態。 然後他補了一句：**他大部分時候都在努力用最先進的 IDE，但真正讓他坐得住的，還是 Emacs。** 這才是這期節目裡最有共鳴的一段，因為它咬住了一個所有技術人都要反覆面對的問題：**該多緊地抱著順手的工具，又該花多少精力去學新的。** ## 社群一年一換的興奮，多數是噪音 Lex 說，社群給你的訊號是嘈雜的。每年都有一批人為了新工具興奮，而你必須做一個判斷：這些東西是在定義新一代的工作方式，還是會改變程式設計這件事的形態，或者只是一陣風，吹完就散。 前端尤其明顯。JavaScript 框架、構建工具、狀態管理方案，一波接一波地來，一波接一波地走。 他舉了自己的例子。Flash 裡的 ActionScript，他認真學過，學怎麼在裡面寫程式，學怎麼在裡面做圖形動畫。Java applet 也是，他當年寫了相當多的 applet，真心覺得這可能是 Web 的未來。 結果不是。 吉多的回應值得逐句讀。他沒有安慰說"你那些時間沒白費"，也沒有附和說"那都是垃圾"。他說的是：**這類技術最終都會死掉，但它們最早引入或者最早讓大眾接觸到的那批概念，會被留下來。** Java applet 早就沒了，可"頁面裡包含一小段程式碼，直接響應你的動作"這個念頭，按下按鈕、點開連結、滑鼠懸停，一點沒退場。Flash 當年做那些動畫做得極其痛苦，後來被 JavaScript 的同類方案取代，那確實是更好的做法，但動畫本身還在，只是換了個載體。 > "技術演化經常是這樣的：那個最終被扔掉的階段，恰恰是讓你能起步的東西。沒有螺旋槳飛機，就不會有噴氣式飛機。"（吉多·範羅蘇姆） Lex 在這裡插了一句反駁，而且插得對。從功能上看是這樣，從使用者角度看也是這樣，可從寫程式碼的那個人角度看呢？那些泡在 ActionScript 裡的時間，那些熬在 Java applet 除錯上的夜晚，怎麼算？ 他沒能把這個問題問完。文字稿到這裡斷了。 ## 什麼能活三十年，什麼活不過五年 不過這條線其實已經被前面的內容回答了，只是答案散在各處，得自己拼。 看吉多怎麼談 Python 的縮排。他說這件事在 Python 裡已經沒有重新討論的餘地，因為花括號已經在語言裡幹了別的活，動這一個決定會連帶扯出一堆東西。他還說，哪怕你認定縮排更好，你也不能回頭去改 C。**一門語言活到一定年頭，它最重要的屬性就從最優變成了穩定。**穩定意味著已經寫下的幾億行程式碼明天還能跑，意味著所有人腦子裡那套肌肉記憶還成立。 再看那筆每千行一個 bug 的賬。這個數字之所以能壓到一，靠的是時間。是無數次上線、無數次線上事故、無數次把邊界條件一條條補上。一個專案真正的資產，往往藏在它踩過的、並且被修掉的那些坑裡，漂亮的設計圖紙反倒排在後面。 Flash 死在第五年，Python 活到第三十年，兩者的差別在語法優雅程度之外。**關鍵變數是它有沒有長出一整套讓幾百萬人協作的基礎設施：包的生態、標準庫、風格共識、向上相容的承諾。**語法可以被抄走，這套東西抄不走。 所以回頭看那些兩年就沒人提的框架，判斷標準其實很樸素：它只是把某件事做得更方便，還是引入了一個會一直留下來的概念？前者是工具，後者是思想。工具會被下一個工具換掉，思想會滲進下一代工具裡，換個名字重新出現。 吉多在訪談裡反覆回到同一個詞：上下文。縮排好不好要看上下文，因為大家都在用花括號。美元符號難用還得留著，因為上下文是五十年前那臺記憶體不夠的機器。一個技術決策是對是錯，很少能在它被做出來的那一刻判斷，得等十年，看它長出什麼。 寫程式碼的人從這條線裡能落下一個有點反直覺的結論。**花在某個具體工具上的時間，可能真的會歸零；花在理解它為什麼這麼設計上的時間，基本不會白費。**ActionScript 的三個晚上，如果只學了語法，那就是三個晚上；如果順手想明白了為什麼在瀏覽器裡跑動畫要這麼費勁，那筆賬十年後還在給你分紅。 Emacs 也是一樣。它四十多年沒死，鍵位設定合理這個理由站不住腳，恰恰相反，那些鍵位是當年那臺機器的鍵盤佈局留下的化石。它活著是因為它允許使用者把編輯器改造成自己想要的東西，這個念頭活得比它自己久，今天所有現代編輯器都在繼承這條思路。 三十多年前，吉多在一個聖誕節前後開始寫一個直譯器，當時的動機只是想做點事情打發時間。**他沒打算設計一門能拿獎的語言，他想設計一個自己願意天天讀的語言，然後堅持了三十年不改主意。**這個決定後來變成了幾百萬人每天上班要用的東西。 這件事裡可複製的部分不多，但有一點：他選的那條路，縮排代替花括號，可讀性大於簡短，從頭到尾沒變過。中間被質疑過，被打過仗，被 Google 的風格指南用兩個空格頂回來過，他都認了，但主幹沒動。 一份菜譜要餵給兩個讀者，一個是機器，一個是人。三十年來所有成功的語言都在回答同一個問題：當兩者打架的時候，你站哪邊。吉多站了人這邊，代價是 Python 在效能上一直被人嘲笑。3.11 那個 10% 到 60% 的提升，是他們在不改語言設計的前提下，回頭去改底層實現拿到的。 不推翻自己，只是把地基挖深一點。長跑選手和短跑選手最大的區別，大概就在這裡。 - 看到"每千行 70 個 bug"這類數字，先問它測的是哪個階段。開發中的程式碼和執行了五年的程式碼，差著一個數量級，混在一起比會得出完全錯誤的結論。 - 隔一段時間去讀自己一年前寫的程式碼。如果讀得毫不費力，說明對方水平和你一樣且思路一致；如果讀得很痛苦，那些痛苦的地方就是你該改的寫法。 - 評估一門新技術，別隻看它讓你寫起來多爽，看它引入了哪個概念。概念會留下，語法會被下一個人推翻。 - 縮排、分號、命名風格這類爭論，交給自動格式化工具，別在會議上花時間。人類的判斷力應該花在演算法選擇和邊界條件上。 - 把"一次寫對"這個念頭從流程裡刪掉。既然成熟程式碼也有千分之一的錯誤率，那就在架構上預留返工的空間，別指望這次不出錯。 - 退格鍵的位置值得認真對待。如果你每天要按幾百次，把它挪到拇指下面，這個改動的投入產出比比大多數效率工具都高。 - 不要因為一個工具"過時了"就否定自己學它的那段時間。檢查一下你從裡面帶走了哪個概念，那個才是真正的收穫。 - 選定一套自己坐得住的工具，別每年重灌一遍環境。舒適區省下的注意力，可以全部投給真正難的問題。