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

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

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

作者 | Daniel Chale     譯者 | 明明如月責編 | 夏萌出品 | CSDN(ID:CSDNnews)

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

代碼:愛的語言

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

設計模式與原則

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

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

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

最佳實踐

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

重視測試

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

共感與尊重

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

結論

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

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

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