重複自己，做超過一件事，並且重寫所有內容

如果你向工程師尋求建議——這是個糟糕的主意——他們可能會告訴你類似這樣的話：不要重複自己；程式應該只做好一件事；永遠不要從頭重寫你的程式碼。

遵循「不要重複自己」可能會導致你寫出一個帶有四個布林值標記的函數，並且在修改程式碼時需要小心地處理各種行為的組合。將事情分割成簡單的單元可能會導致尷尬的組合，並且難以協調交叉性的更改。避免重寫意味著它們經常被拖延到很晚，以至於沒有成功的機會。

這些建議本身並不壞——儘管出發點是好的，但完全照字面意思執行可能會造成比它承諾解決的更多問題。

有時候遵循一個格言的最佳方式是做完全相反的事：擁抱功能開關並持續重寫你的程式碼，將事物整合在一起使它們之間的協調更容易管理，並且重複自己以避免在一個函數中實現所有功能。

不幸的是，這個建議更難遵循。

重複自己以發現抽象化

「不要重複自己」幾乎是一個自明之理——如果說有什麼的話，程式設計的重點就是避免重複工作。

沒有人喜歡寫樣板程式碼。寫起來越直接，在文字編輯器中敲打出來就越無聊。人們在還沒開始寫之前就已經厭倦了寫出完全相同程式碼的八個副本。你不需要說服工程師不要重複自己，但你確實需要教導他們如何以及何時避免它。

「不要重複自己」經常被解釋為「不要複製貼上」或避免在程式碼庫中重複程式碼，但避免重複的最佳形式是避免重新實現已經存在於其他地方的東西——而且幸運的是，我們大多數人已經在這樣做了！

幾乎每個網路應用程式都heavily依賴作業系統、資料庫和各種其他程式碼來完成工作。現代網站在不經意間就重複使用了數百萬行程式碼。不幸的是，工程師喜歡避免重複，而「不要重複自己」變成了「總是使用抽象化」。

說到抽象化，我指的是兩個相互關聯的事物：一個我們可以思考和推理的概念，以及我們在程式語言中對它建模的方式。抽象化是一種重複自己的方式，這樣你就可以在一個地方更改程式的多個部分。抽象化允許你管理系統中的交叉性更改，或在其中共享行為。

總是使用抽象化的問題在於，你在預先猜測程式碼庫的哪些部分需要一起更改。「不要重複自己」將導致一個僵硬的、緊密耦合的程式碼混亂。重複自己是發現你實際需要哪些抽象化（如果有的話）的最佳方式。

正如Sandi Metz所說：「重複遠比錯誤的抽象化便宜」。

你實際上無法預先寫出一個可重用的抽象化。大多數成功的函式庫或框架都是從一個更大的運作中的系統中提取出來的，而不是從頭開始創建的。如果你還沒有用你的函式庫構建出有用的東西，其他人也不太可能會用它。程式碼重用不是避免重複程式碼的好藉口，而且在你的專案中寫可重用的程式碼通常是一種過早優化的形式。

當涉及到在你自己的專案中重複自己時，重點不是能夠重用程式碼，而是進行協調性的更改。在你確定要將事物耦合在一起時使用抽象化，而不是為了機會主義或意外的程式碼重用——重複自己以找出何時需要這樣做是可以的。

重複自己，但不要重複其他人的辛勤工作。重複自己：首先重複以找到正確的抽象化，然後去除重複以實現它。

關於「不要重複自己」，有些人堅持認為這不是關於避免程式碼重複，而是關於避免功能重複或責任重複。這更普遍地被稱為「單一責任原則」，而且同樣容易被誤解。

匯聚責任以簡化其之間的互動

當談到將大型服務拆分成小塊時，一種想法是系統中的每個部分應該只做一件事——做好一件事——希望通過遵循這個規則，變更和維護會變得更容易。

這在小範圍內運作良好：將變數用於不同目的是一個永恆存在的錯誤來源。在其他地方就不那麼成功了：儘管一個類可能以相當糟糕的方式做兩件事，但當你最終得到兩個糟糕的類，它們之間有著更複雜的連接混亂時，解開它並沒有多大好處。

將事物推到一起和將事物分開的唯一真正區別是，某些更改變得比其他更改更容易執行。

整體架構和微服務之間的選擇是另一個例子——在開發和部署單一服務，或是由較小的、獨立開發的服務組成的選擇之間。

它們之間的最大區別是，在一個中進行交叉性更改更容易，而在另一個中進行局部更改更容易。哪一個最適合團隊通常更多地取決於環境因素，而不是正在進行的具體更改。

儘管當需要添加新功能時，整體架構可能會很痛苦，而當需要協調時，微服務可能會很痛苦，但整體架構可以通過功能標記和短期分支順利運行，而當部署容易且高度自動化時，微服務也能很好地工作。

即使是整體架構也可以在內部分解為微服務，儘管是在單一儲存庫中並作為一個整體部署。所有事物都可以被分解成更小的部分——訣竅是知道何時這樣做是有利的。

模組化不僅僅是將事物減少到最小的部分

援引「單一責任原則」，工程師已知會殘酷地將軟體分解成驚人數量的小型互鎖部件——這種工藝很少在昂貴的手錶或bash之外見到。

傳統的UNIX命令列展示了只執行一個功能的小型元件，要發現你需要哪一個以及如何使用它來完成工作可能是一個挑戰。將東西導入到 awk '{print $2}' 幾乎是一種成年禮。

git是單一責任原則的另一個例子。儘管你可以使用git checkout對儲存庫做六種不同的事情，但它們在內部都使用類似的操作。儘管具有單一功能，元件可以以非常不同的方式使用。

沒有共享功能的小型元件層創造了對上層的需求，這些功能在這裡重疊，如果缺乏，使用者將創建一個，通過bash別名、腳本，甚至是用於複製粘貼的電子表格。

即使添加這一層可能也幫不了你：git已經有了面向使用者和面向自動化的命令的概念，但UI仍然是一團糟。為現有命令添加新標記總是比複製它並平行維護更容易。

同樣，隨著程式碼庫需求的變化，函數獲得布林值標記，類獲得新方法。在試圖避免重複並將程式碼放在一起時，我們最終將事物糾纏在一起。

儘管元件可以用單一責任創建，但隨著時間推移，它們的責任將以新的和意想不到的方式改變和互動。模組目前在系統中負責的內容不一定與它將如何發展相關。

模組化是關於限制增長的選項

給定的模組經常被更改，因為它是最容易更改的模組，而不是進行更改的最佳位置。最終，定義模組的是系統中它永遠不會負責的部分，而不是它目前負責的部分。

當一個單元對不能包含什麼程式碼沒有規則時，它最終將包含越來越多的系統。這對於每個名為'util'的模組來說永遠是真實的，這也是為什麼在Model-View-Controller系統中幾乎所有東西最終都在控制器中。

理論上，Model-View-Controller是關於三個互鎖的程式碼單元。一個用於資料庫，另一個用於UI，還有一個用於它們之間的粘合劑。在實踐中，Model-View-Controller類似於具有兩個不同子系統的整體架構——一個用於資料庫程式碼，另一個用於UI，兩者都嵌套在控制器內。

MVC的目的不僅僅是將所有資料庫程式碼放在一個地方，還要將它遠離前端程式碼。我們擁有的資料以及我們想要查看它的方式將隨時間獨立於前端程式碼而改變。

儘管程式碼重用是好的，較小的元件也是好的，但它們應該是其他期望變更的結果。兩者都是權衡，通過缺乏冗餘引入耦合，或在事物如何組合方面引入複雜性。將事物分解成更小的部分或統一它們對程式碼庫來說既不是普遍好也不是普遍壞，很大程度上取決於之後會發生什麼變化。

就像抽象化不是關於程式碼重用，而是為了變更而耦合事物一樣，模組化不是關於按功能將相似的事物組合在一起，而是找出如何讓事物分開並限制整個程式碼庫的協調。

這意味著要認識哪些部分比其他部分稍微更糾纏，知道哪些部分需要相互溝通，哪些需要共享資源，什麼共享責任，最重要的是，存在什麼外部約束以及它們向哪個方向移動。

最終，這是關於為這些變更優化——這很少通過追求可重用的程式碼來實現，因為有時處理變更意味著重寫所有內容。

重寫一切

通常，重寫只有在成為唯一選擇時才是實際可行的選項。技術債務，或是我們不能無禮評論的資深工程師寫的程式碼，累積到所有更改都變得危險。只有當系統到達臨界點時，重寫才會被考慮為一個選項。

有時原因可能不那麼戲劇性：一個API被關閉了，一個新創公司完成了美好的旅程，或者城裡有了新的時尚潮流和上級追逐它的命令。重寫也可能發生在安撫工程師時——用一個單獨的專案來獎勵良好的團隊合作。

重寫在實踐中如此冒險的原因是，用另一個系統替換一個運作中的系統很少是一夜之間的改變。我們很少理解先前的系統做了什麼——它的許多特性本質上是偶然的。文檔稀少，測試是裝飾性的，介面本質上是有機的，頑固地將行為鎖定在適當的位置。

如果遷移到替代系統取決於一次性切換所有內容，請確保你提前預訂了過渡期間的假期。

成功的重寫會計劃新舊系統間的遷移，計劃逐步增加現有負載，並計劃處理事物同時存在於一個或兩個地方的情況。兩個系統都持續維護，直到其中一個可以被停用。在較大的系統上，緩慢、謹慎的遷移是唯一可靠的選擇。

要成功，你必須先從困難的問題開始——通常與性能相關——但也可能涉及處理最困難的客戶，或系統最大的客戶或使用者。重寫必須由分類驅動，將問題範圍縮小到可以有效改進的程度，同時由當前的更大問題引導。

如果替換系統在三個月後仍然沒有做出任何有用的事情，那麼它很可能永遠不會做出任何有用的事情。

在生產環境中運行替換系統所需的時間越長，找到錯誤所需的時間就越長。不幸的是，遷移因功能開發而被推遲。新專案有最多的功能膨脹空間——這被稱為第二系統效應。

第二系統效應是典型的注定失敗的重寫的名稱，其中計劃了大量功能，實現的不夠多，而且已經寫好的很少能可靠工作。這類似於在沒有遊戲來指導決策的情況下寫遊戲引擎，或在沒有內部產品的情況下寫框架。結果的程式碼是一個無約束的混亂，幾乎不適合其目的。

我們說「永遠不要重寫程式碼」的原因是我們把重寫留得太晚，要求太多，並期望它們立即工作。永遠不要倉促重寫比完全不重寫更重要。

空值為真，一切皆允許

完全按照建議行事的問題是它在實踐中很少有效。不惜一切代價遵循它的問題是，最終我們無法承擔這樣做的代價。

它不是「不要重複自己」，而是「一些冗餘是健康的，一些不是」，並且在你確定想要將事物耦合在一起時使用抽象化。

它不是「每個事物都有一個獨特的組件」，或單一責任原則的其他變體，而是「如果介面之間簡單，將部分解耦成更小的部分通常是值得的，並試圖讓快速變化和難以實現的部分彼此遠離」。

它永遠不是「不要重寫！」，而是「不要放棄正在工作的東西」。建立遷移計劃，並行維護，然後最終停用。在高速增長的情況下，你可能可以推遲停用，甚至可能推遲遷移。

當你聽到一個建議時，你需要理解使它成為真理的結構和環境，因為它們同樣經常使它成為假的。像「不要重複自己」這樣的事情是關於做出權衡，通常在小範圍內或對初學者來說一開始複製是好的，但在較大的系統上不加質疑地調用是危險的。

在較大的系統中，理解我們的設計選擇的後果要困難得多——在許多情況下，這些後果只有在過程中太晚太晚時才被發現，只有通過將更多的工程師投入坑中才有完成的希望。

最終，我們將我們的好決定稱為「乾淨的程式碼」，將壞決定稱為「技術債務」，儘管遵循相同的規則和實踐來達到那裡。

撰寫程式碼時，應著重於簡單易刪與易除錯

可除錯的程式碼是那種不會讓你摸不著頭緒的程式。有些程式碼會比較難除錯，原因可能是隱含的行為、不良的錯誤處理、含糊不清的邏輯、結構過於鬆散或過於緊密，亦或是處於改動中的程式碼。在一個足夠大的專案中，你最終會遇到自己無法理解的程式碼。

在一個夠老舊的專案中，你甚至會發現連自己曾寫過的程式碼都不記得了——如果不是因為提交記錄的存在，你甚至會懷疑這些程式碼是別人寫的。隨著專案規模的增長，記住每段程式碼的功能會越來越困難，尤其當這些程式碼無法正常運作時更是如此。在無法理解的程式碼上進行修改，最終你只能透過除錯的方式去了解它。

撰寫易於除錯的程式碼，從意識到未來你將無法記住這些程式碼開始。

規則0：良好的程式碼應具備明顯的錯誤

有許多方法論的推銷者認為，撰寫可理解的程式碼應該著重於「乾淨的程式碼」。然而，問題在於「乾淨」的定義往往依情境而異。乾淨的程式碼可能是硬編碼進系統中的，某些骯髒的快速修正反而可以輕鬆移除或停用。有時候，程式碼之所以顯得乾淨，只是因為其他複雜的部分被移到別處。

程式碼的乾淨與否，更大程度上反映了開發者對自身工作的自豪或羞愧，而非它的易維護性或可變更性。因此，比起所謂的「乾淨」，我們更需要的是「無趣」的程式碼，這樣的程式碼使變更點顯而易見——我發現，當專案留下許多簡單問題等待他人解決時，更容易吸引其他人參與。

良好的程式碼應具備以下特徵：

• 不試圖掩蓋醜陋的問題，亦不試圖讓無趣的問題看起來有趣。
• 錯誤顯而易見，行為清晰可辨，而非隱晦不明。
• 清楚記錄自身的不足，而非試圖追求完美。
• 行為足夠直觀，以致於任何開發者都能想出無數種變更方式。
• 即便是極其糟糕的程式碼，有時過於追求清潔反而會帶來更大的問題。

並非乾淨的程式碼不好，而是過度強調「乾淨」有時反而更像是將問題掃進地毯下。可除錯的程式碼不一定乾淨，而充滿檢查與錯誤處理的程式碼，也未必令人愉悅。

規則1：電腦永遠處於「起火」狀態

電腦「著火」，而且程式上次執行時已崩潰。

程式執行的第一件事，應是確保自己從一個已知的、良好的、安全的狀態啟動，而非盲目進行任務。有時，因為使用者刪除了狀態文件或升級了系統，無法獲取乾淨的狀態副本。儘管程式上次執行時崩潰了，但現在卻被視作第一次執行。

例如，在讀寫程式狀態至檔案時，可能會發生以下問題：

• 檔案遺失
• 檔案損毀
• 檔案版本過舊或過新
• 檔案最後的變更未完成
• 檔案系統撒了謊

這些並非新問題，資料庫從古至今（1970-01-01起）便一直在處理這些狀況。使用像 SQLite 這樣的工具，可以解決許多類似問題。然而，如果程式上次執行時崩潰，可能會導致後續以錯誤的資料或方式執行程式。

以排程程式為例，你可以確定以下事故將會發生：

• 由於日光節約時間的變更，在同一小時內被執行兩次。
• 因為操作人員遺忘已執行過，導致再次執行。
• 因為磁碟空間不足或雲端網路異常，錯過一個小時的排程。
• 執行時間超過一小時，延遲後續排程。
• 在錯誤的時間點執行。
• 接近午夜、月末或年底等邊界時間點執行時，因數學運算錯誤而失敗。

撰寫健壯的軟體，應假設程式上次執行時已崩潰，並在程式無法確定正確行為時選擇崩潰。與其留下「這不應該發生」的註解，直接拋出例外更有助於除錯，因為當問題發生時，你至少有除錯的起點。

你不必能夠處理所有這類問題——僅需讓程式停止並避免進一步惡化即可。小型檢查機制能夠大幅節省排查日誌的時間，而一個簡單的鎖檔機制則能避免耗費數小時進行備份還原。

易於除錯的程式碼應具備以下特性：

• 執行前先檢查條件是否正確。
• 使程式能夠輕鬆回到已知的良好狀態並重新嘗試。
• 透過多層防禦機制盡早讓錯誤浮現。

規則 2：你的程式正在與自身對抗

Google 最嚴重的 DoS 攻擊往往來自自身系統，這是因為我們擁有非常龐大的系統。雖然偶爾會有外部人士嘗試挑戰我們的極限，但真正來說，沒有人比我們更擅長把自己「打趴」。

這對所有系統來說都是一樣的。
——Astrid Atkinson，《Engineering for the Long Game》

軟體總是會在上次執行時崩潰，現在它則總是耗盡 CPU、記憶體與磁碟資源。所有工作程序都在處理空佇列，所有人都在重試早已失效的請求，而所有伺服器同時因垃圾回收機制暫停執行。不僅系統故障，系統本身還在不斷地試圖破壞自己。

甚至要確認系統是否正在執行本身就相當困難。

檢查伺服器是否運作相對容易，但要檢查它是否正在處理請求則困難得多。如果你不檢查執行時間，程式可能會在每次檢查之間不斷崩潰。有時健康檢查甚至可能觸發程式錯誤：我曾經兩次在不同時間點設計出導致系統崩潰的健康檢查機制。

在軟體中，撰寫處理錯誤的程式碼最終會發現更多需要處理的錯誤，其中許多甚至是錯誤處理本身導致的。同樣地，效能優化往往成為系統瓶頸的來源——一個在單一標籤中使用流暢的應用程式，當同時開啟二十個標籤時可能會變得難以使用。

另一個例子是當管線中的工作程序執行速度過快，導致在下一個部分有機會跟上之前，耗盡了可用記憶體。用車流來比喻：交通阻塞通常是因為過快的車流造成的，阻塞會以回饋形式向後延伸。某些優化會在高載或重載時導致系統以難以預測的方式失效。

換句話說：系統越快，負載越高；若不設法讓系統適度回應，別驚訝它會崩潰。

回壓（Back-pressure）是一種系統內部的回饋機制，而易於除錯的程式碼，是能夠讓使用者參與回饋循環的程式碼，並能讓使用者了解系統的所有行為，包括意外、預期與非預期的行為。易於除錯的程式碼應該是容易檢查的，能讓你觀察並理解其內部變化。

規則 3：現在不消除歧義，以後就得花時間除錯

換句話說：看著程式中的變數，應該能夠輕鬆推斷發生了什麼事。除了一些令人恐懼的線性代數子程序外，你應該努力使程式的狀態表示得儘可能直觀。這意味著不要在程式中途改變變數的用途。若要指出一項明顯的嚴重錯誤，那就是用同一個變數表示兩種不同的目的。

這同樣意味著要謹慎避免「半謂詞問題」（Semi-predicate Problem），即不要用單一值（如計數器）來表示兩個值（布林值與計數器）。避免使用類似返回正數代表結果，返回 -1 代表無匹配結果的方式。原因在於你可能會遇到需要「0，但為真」這類情況（Perl 5 就有這種特性），或是產生難以與系統其他部分組合的程式碼（-1 在下一部分程式中可能是合法輸入，而非錯誤）。

除了單一變數用於兩個目的外，使用一對變數表示單一目的也同樣糟糕——尤其當這些變數是布林值時。我指的並不是用一對數字來表示範圍不好，而是用多個布林值來表示程式的狀態，通常暗示著隱藏的狀態機。

當狀態不從上到下順序流動時，最好為狀態建立單獨的變數並簡化邏輯。如果你在物件中有一組布林值，可以將其替換為名為 state 的變數，並使用列舉型別（enum）或字串（若需持久化）。這樣，if 語句會變成 if state == name，而非 if bad_name && !alternate_option。

即使你明確表達了狀態機，也可能會出錯：有時候程式碼中隱藏了兩個狀態機。我在撰寫 HTTP Proxy 時就曾遇到極大的困難，直到我分別為連接狀態與解析狀態建立各自的狀態機，才順利解決問題。當你將兩個狀態機合併為一個時，很難新增新狀態或準確判斷當前狀態應該是什麼。

這更多是關於創造不需要除錯的東西，而非使其易於除錯。通過列出有效狀態，可以更輕鬆地直接拒絕無效狀態，而不是不小心讓一兩個無效狀態通過。

規則 4：意外行為即為預期行為

當你對資料結構的功能不夠清晰時，使用者會自行填補空白——無論是預期中的行為或是意外行為，最終都會在其他地方被依賴。許多主流程式語言的雜湊表可以遍歷，這種行為大多數情況下會保留插入順序。

有些語言選擇讓雜湊表按照使用者的預期行為進行——依照添加順序遍歷鍵，而另一些語言則選擇每次遍歷時返回不同順序的鍵。在後者情況下，部分使用者便抱怨這樣的行為不夠隨機。

悲哀的是，程式中的任何隨機性最終會被用於統計模擬，或更糟的是，用於加密，而任何排序的來源則會被用於排序操作。

在資料庫中，有些識別碼包含的資訊比其他的更多。當創建資料表時，開發者可以選擇不同類型的主鍵。正確的選擇是 UUID 或與 UUID 相似的東西。其他選擇的問題在於，它們除了身份外，還暴露了排序資訊，即不僅能知道 a == b，還能知道 a <= b，而這些其他選擇指的就是自增主鍵。

自增主鍵是資料庫為每一行分配數字，在插入新行時會增加 1。這會產生一種模糊性：人們不知道哪部分資料是「權威的」。換句話說：你是按主鍵排序，還是按時間戳排序？正如之前對於雜湊表的情況，人們會自行決定正確答案。另一個問題是，使用者很容易猜出附近記錄的其他鍵值。

最終，任何試圖比 UUID 更聰明的做法都會適得其反：我們曾經嘗試過郵政編碼、電話號碼和 IP 位址，並且每次都以慘敗告終。UUID 也許不會讓你的程式碼更容易除錯，但較少的意外行為往往意味著較少的錯誤。

排序並不是唯一會從鍵中提取的資訊：如果你創建的是由其他欄位構成的資料庫鍵，使用者將會拋棄原始資料，僅從鍵中重建。現在你有兩個問題：當程式狀態被存儲在多個地方時，副本之間很容易產生不一致。如果你不確定該修改哪一個，或者不確定自己已經修改了哪一個，那麼保持同步會變得更加困難。

無論你允許使用者做什麼，他們都會去實現。撰寫易於除錯的程式碼是對它可能被濫用的方式進行前瞻性思考，並考慮其他人如何與其互動。

規則 5：除錯是社交的，先於技術的

當一個軟體專案分散於多個組件和系統時，發現錯誤會變得更加困難。一旦你理解了問題的發生原因，可能需要在多個部分協調更改才能修正行為。修復大型專案中的錯誤，更多的是關於說服其他人相信這些錯誤是實際存在的，甚至說服他們修復是可能的。

錯誤在軟體中持續存在，因為沒有人能完全確定誰對哪些部分負責。換句話說，當一切都沒有書面記錄、所有問題都必須在 Slack 上詢問，而且直到唯一知道答案的人登入之前，什麼問題都無法解決，那麼程式碼的除錯就變得更加困難。

計劃、工具、流程和文檔是解決這些問題的途徑。

計劃是如何移除待命的壓力，建立結構來處理事件。計劃是如何保持客戶通知，當人員待命過久時更換人手，並跟蹤問題以進行變更以降低未來風險。工具是將工作簡化並使其對他人可用的方法。流程是如何將控制從個人轉交給團隊的方式。

人員會變動，互動也會變，但隨著時間推移，團隊會繼續沿用這些流程和工具。問題不在於某一方是否比另一方更重要，而是如何構建一種支持彼此變化的方式。流程也可以將控制移出團隊，所以它並非總是好或壞，但總有某種流程在運作，即使它沒有書面記錄，記錄下來的行為是讓其他人改變它的第一步。

文檔不僅僅是文字檔：文檔是如何交接責任，如何讓新成員快速了解情況，如何將變更傳達給受影響的人。撰寫文檔需要比撰寫程式碼更多的同理心，並且需要更多的技能：沒有簡單的編譯器標誌或型別檢查器，寫下大量文字卻無實際內容也很容易。

如果沒有文檔，怎麼能指望使用者做出明智的決策，或同意使用軟體的後果呢？如果沒有文檔、工具或流程，你無法分擔維護負擔，甚至無法替換當前被賦予這項任務的人。

讓程式碼易於除錯同樣適用於圍繞程式碼的流程，讓程式碼變得清晰，知道為了修正程式碼你需要踩到哪些人的腳。

易於除錯的程式碼也容易解釋。
在除錯過程中，常見的情況是當你解釋問題給別人聽時，自己會意識到問題所在。對方甚至不必存在，但你確實需要強迫自己從頭開始解釋情況、問題及重現步驟，這樣的框架往往足以讓我們洞察答案。

如果可以的話。有時候，當我們尋求幫助時，我們並未詢問正確的問題，這也是我常犯的錯誤——這是如此常見的困擾，以至於有個名字：“X-Y 問題”：我該如何獲取檔案名稱的最後三個字母？哦？不，我是指檔案副檔名。

我們會根據自己理解的解決方案來談論問題，並根據已知的後果來談論解決方案。除錯是一種艱難的學習過程，學會面對意外後果和替代方案，並承認自己錯誤，這是工程師最難做到的事之一：承認自己搞錯了。

畢竟，這並不是編譯器的錯。