優秀的代碼就像一封情書，別讓祖傳代碼被稱為「屎山」！

【編者按】編程是一種交流的方式，優秀的代碼就像一封情書，個體化、真誠、深思熟慮，使用設計模式與原則構造，遵循最佳實踐和重視測試，表達對讀者的共感和尊重，是開發者留給後續開發者的持久遺產。

原文鏈接：https://addyosmani.com/blog/good-code/

我們有時候對編程有著過於理想化的認識，將其看作是一種抽象的藝術、科學，甚至賦予了神秘的魔力。然而，現實情況卻更為務實。從根本上說，代碼是一種交流的方式。在我撰寫的《學習 JavaScript 設計模式》一書中，我有句引言：「優質的代碼如同寫給後續開發者的一封情書。」 這就是跨越時間與空間的深情交流，從一位開發者傳遞到另一位開發者。

情書是充滿個人色彩、真誠、深思熟慮的，它以詩意的方式表達了情感，經常通過精心選擇的詞句準確地傳達感情。優秀的代碼同樣擁有這些特性。它具有個體化的特點，因為代碼反映了程序員的邏輯思維和問題解決方法。優秀的代碼需真誠，避免不必要的複雜性。它需要深思熟慮，考慮到下一個解讀它的開發者。最重要的是，優秀的代碼需精心設計，其目標是以最高效的方式解決問題。

正如我們有語法規則和句子結構來構造語言，以便情感可以被理解，我們也有設計模式和原則來構建代碼。這些模式使得代碼可擴展、可維護、高效，並且易讀和易理解。設計模式提供了一種開發者共享的語彙，使他們能以公認的結構表達複雜的軟體設計。

因此，優質的代碼會有策略地運用這些模式，就像經驗豐富的詩人會運用詩詞技巧來創造共鳴一樣。使用這些模式的目的並非僅僅為了使用，而是因為這些模式增強了解決方案的價值，使代碼更易於理解，並確保代碼庫的持久性。

SOLID（單一職責原則、開閉原則、里氏替換原則、介面隔離原則和賴反轉原則英文首字母構成的單詞）、DRY （ Don't Repeat Yourself，強調避免在代碼中出現重複的邏輯或信息）、KISS （Keep It Simple, Stupid。強調設計和實現軟體時，應該盡量保持簡單和直接，避免過度複雜化）和 YAGNI （ You Ain't Gonna Need It。核心思想是在編寫代碼時，不要去實現當前不需要的功能，也不要為未來可能需要的功能增加複雜性）不僅是原則，開發者更將它們視為編寫優秀代碼的基石。它們引導開發者做出明智的決策，在過度設計和過度簡化之間找到平衡，最終，創造出一份會被接收者珍視的"代碼情書"。

優秀的代碼遵循已經確認的最佳實踐，這就像在寫情書時需要遵守的社交禮儀。適當的命名規則、模塊化的設計以及詳盡的注釋都是其中的一部分。這些不僅僅是需要遵守的規則，更是衡量編程者在代碼中對後續開發者是否負責的標準。它們的存在就是為了確保在代碼的理解和傳遞過程中，程序員的初衷不會丟失。

如同作者會對他們的作品進行校對一樣，開發者也應對自己的代碼進行測試。嚴謹的測試和測試驅動開發（TDD）是精心編寫的代碼的重要標誌。測試能在各種環境下驗證代碼的性能，揭示潛在的缺陷和盲點。強大的測試框架往往就是代碼質量的有力保證。

最重要的是，情書的核心在於對讀者的共感和尊重，優秀的代碼同樣如此。編寫出其他人可以閱讀、理解和維護的代碼，是一種對專業的尊重。這表明程序員理解他們的工作是更大的、持續的努力的一部分，軟體是一個不斷演進的實體，並且會有許多人在時間的推進中影響其命運。

最後，編程是一種創造性的活動，與寫詩或畫畫有共通之處。然而，我們的創作之美並非僅僅由我們的演算法的優雅或代碼的效率決定，而是取決於他人是否能愉快、輕鬆地在我們的成果之上進一步構建。作為開發者，我們的職責不僅是解決當下的問題，也要確保我們的工作不會成為未來的困擾。

因此，我們編寫的優秀代碼不僅僅是一封情書，更是我們留給後續開發者的寶貴遺產。

你是否認同優秀的代碼就像一封情書？你是否見過如情詩一樣的優雅代碼？你認為優秀的代碼應該是怎樣的？