讓代碼運行起來，比代碼可讀性重要

"代碼的閱讀勝於編寫" 這句話現在已經是程序員共識，它提醒我們，在編寫代碼時不能僅追求方便，而忽視那些將來需要閱讀和修改代碼的人。更一般地說，"代碼的閱讀勝於編寫" 傳達了一個觀點：通過保持代碼可維護性，保持簡潔、編寫測試和文檔等方式來使得代碼易於理解是一個明智的投資。它關乎對軟件開發週期的全局視角。

讓我用更簡潔的表達方式來表述這個觀點：

維護者 > 作者

我認爲這種思路可以超越編寫代碼，並作爲一個經驗法則用於問題識別和決策。

代碼的使用勝於閱讀

代碼只是達到目標的手段。軟件應該有一個目的，它應該爲用戶提供服務。無論代碼是否編寫良好、可維護性如何，以及所使用技術是否先進，如果軟件不能實現其目標並給用戶帶來良好體驗，則一切都沒有意義：

用戶 > 維護者 > 作者

或者，既然我們不再需要區分開發人員角色：

用戶 > 開發者

因此，與其猜測或詢問用戶需求，最好的方法是儘早、頻繁地將程序放在用戶面前，並結合他們的反饋來改進。

這是一個強大的思維模式，只要在開發過程中牢記用戶，我們就能走得更遠。這大致是我學習這個職業以及我職業生涯前半段對它的理解方式。

代碼的運行勝於閱讀

當我說 "運行" 時，我不僅指執行程序，還包括在生產環境中操作它，包括部署、升級、觀察、審計、監控、修復和廢棄等等。正如丹・麥金利所說：在保持系統可靠工作方面，長期成本幾乎總是遠遠超過你在構建過程中遇到的任何不便。

我們可以將這個觀點納入我們的小模型中：

用戶 > 運維 > 開發

我花了一些時間才完全理解這一點，因爲根據我的經驗，很多正在構建的軟件實際上從未真正投入生產使用，至少沒有達到重要規模。大多數軟件都是基於從未經過測試的假設構建而成。但當你將代碼運行在生產環境中時，簡潔性原則就有了新的維度。它不再僅僅關乎代碼本身，而是關乎減少移動部件並瞭解其故障模式。它關乎交付產品並確保即使在出現故障時也能正常工作。

此外，還有商業因素

我說過，在開發過程中牢記用戶可以幫助我們走得更遠。這適用於軟件對用戶有價值且良好運行的假設。對於開發人員來說，這是一個方便的抽象：我們提供優秀、可工作的軟件，而業務則負責將其轉化爲利潤。這在消費者和企業軟件領域通常有效。但最終，這種抽象會被證明是一種過度簡化，並且我們可以從中受益，將一些商業觀點納入我們的工作流程：

商業 > 用戶 > 運維 > 開發

最明顯的例子就是預算：我們沒有無限資源來滿足用戶需求，所以需要衡量成本和收益。還有市場營銷、截止日期、利益相關者和投資者等因素。個人興趣和政治也會產生影響。某些決策在孤立考慮我們的軟件、團隊或用戶時是合理的，但當考慮整個組織時可能不再合適。有時，我們需要關注能夠產生收入的事務，而不是隻迎合用戶。我將再次回到這個問題。

反向思考

我們得到了一個小模型，它表達了軟件開發中各種因素的相對重要性，或許可以幫助我們看到更大的圖景並專注於重要的事情。現在我想看一下一些常見的軟件開發功能障礙，並看看它們如何與該模型相匹配。

難以維護的代碼

作者 > 維護者

這是我們起點。這是聰明而懶惰的代碼變成了意大利麪條和鬼屋，這是過早優化，這是隻有卡洛斯才能碰觸那個模塊等等。

不可用的軟件

開發者 > 用戶

由那些不從用戶那裡學習或將技術放在第一位的團隊製作的軟件。過度工程化程序、惡化用戶體驗的 "現代化"、破壞瀏覽器功能的 Web 應用等等。

只在我的機器上運行

開發者 > 運維

沒有考慮操作問題而設計出來的軟件。這是過於複雜、有很多移動部分、爲小數據負載設計高級數據庫、由單個小團隊管理的微服務生態系統。這是過早爲規模而架構的軟件。這是由與在它出現故障時被叫醒的人不同的人設計的軟件。

正確的事情

開發者 > 商業

將代碼視爲目標本身。這是自命不凡的工匠們、泰坦尼克號上的音樂家和 Lisp 黑客製作的軟件。

以簡歷爲導向的開發

開發者 > *

沒有風險，開發人員可以做他們想做的任何事情。

虛構的軟件

商業 > 用戶 > 運維 > 開發

這是已經構建但很少（或從未）投入生產使用的軟件。我稱之爲虛構的軟件。Charity Majors 稱之爲活在謊言中。

商業 > 用戶 > 運維 > 開發

另一種虛構的軟件是那些沒有用戶但具有可擴展性（大規模）的軟件。這是無法解決問題或解決錯誤問題，可能沒有人關心問題。這種軟件源於採用一些炒作技術並將其應用於所有事物，直到出現模糊地符合某個用例需求。

晚期資本主義

商業 > 用戶 > 運維 > 開發

風險投資支持下沒有商業模式或其商業模式是增長至壟斷然後剝削用戶的軟件。

全局來看

如果你還沒有關閉瀏覽器標籤，讓我總結一下：

商業 > 用戶

這個觀點可能很難接受。

正如我上面提到的，我學習這個工作時，軟件是爲最終用戶解決問題的。這在《程序員修煉之道》的最後一個提示中得到了總結，該提示說我們的目標是讓用戶滿意，而不僅僅是交付代碼。但自從我開始從事程序員工作，並且隨着軟件變得無處不在，我發現這種假設越來越難以維持。

有很多正在生產的軟件根本不關心其用戶，或者操縱用戶，或者將其變成產品。這不僅限於社交媒體：作爲用戶，在沒有彈窗試圖吸引我的注意力之前，我甚至不能預訂房間、訂購食物或點擊 Windows 開始按鈕；在進行谷歌搜索時，我會得到一堆垃圾信息。

我們認爲做好工作意味着什麼與行業中相當大一部分人認爲能夠獲利是相矛盾的，我認爲這解釋了許多軟件專業人士日益感到不適的原因。雖然我們不能迴避對我們領域的經濟現實，但也許我們應該更加堅定地站在道德立場上，不傷害用戶。承認用戶並非始終排在商業之前，但商業也不應無條件地居於第一位：

用戶 > 運維 > 開發商業 > 運維 > 開發

商業 ≹ 用戶

原文鏈接： https://olano.dev/2023-11-30-code-is-run-more-than-read