10個改變程式設計思維的經典隨筆
塑造我們思維的程式設計隨筆
程式設計不僅只是寫代碼；它是一門需要審慎思考、創造性解決問題和深入理解的豐富學科。對於那些對程式設計的藝術和科學感興趣的人，某些隨筆成為了影響我們軟體開發方法的基礎閱讀。這個系列強調了影響深遠的程式設計隨筆，這些隨筆持續地塑造著開發者對其技藝的思考。
理解計算系統
能夠改變程式員效能的一個最深刻的信念是，電腦儘管複雜，但仍是可以理解的。正如 Nelson Elhage 在他的隨筆電腦是可以理解的中所闡述的，相信系統是可理解的，而不是將其視為不可接近的黑箱，這種思維打開了更深層次問題解決的可能。
Elhage 注意到，「在某些方面，這種信念今天感覺起來很激進。現代軟體和硬體系統在多個獨立層次中包含了幾乎無法想像的複雜，每一個層面建造在其他層的基礎上。」儘管這種複雜性，Elhage 反對將系統視為黑箱：「你不可能理解堆疊中每個層次的每個細節；但你能以某種程度上的抽象理解它們，並能夠以必要的深度理解任何特定層級所需的目的。」
這種以相信其可理解性來接觸複雜系統的理念構成了真正技術嫺熟的工程工作的基礎。它抵制了面對複雜性時放棄的誘惑，反而鼓勵一種有系統的、好奇的方法來探索技術。
技術保守主義的價值
當選擇專案的技術時，Dan McKinley 的隨筆選擇無聊技術提供了寶貴的智慧，使無數開發團隊免於不必要的痛苦和複雜。
McKinley 引入了「創新代幣」的概念——每家公司擁有的有限資源：「假設每家公司大約有三個創新代幣。你可以隨意使用這些代幣，但供應在長時間內是固定的。」這種心智模型幫助團隊在那裡投入創新精力時更有意識。
隨筆指出，使用新的、未經驗證的技術會消耗這些寶貴的代幣：「如果你選擇用 NodeJS 編寫網站，你就耗掉了一枚創新代幣。如果你選擇使用 MongoDB，你就耗掉了一枚創新代幣。」意味很明確——將你的創新用在對你的業務真正重要的地方，而不是在對競爭優勢沒有直接貢獻的流行技術上。
這種指導特別對於資源有限、專注力至為重要的初創公司和成長型企業來說價值非凡。通過為大部分技術棧選擇經驗證的技術，你可以保留在真正重要之處創新的能力。
過早抽象的危險
「不要重複自己」（DRY）原則一直是程式設計建議的基石。然而，Sandy Metz 的隨筆錯誤的抽象挑戰這種傳統智慧，指出過早創建的抽象如何隨著時間推移導致增加的複雜性。
Metz 描述了一種常見情況，即初始抽象隨著新需求出現而變得愈加複雜：
- 時間流逝。
- 出現了一個新需求，現有的抽象幾乎是完美的。
- 程式員B感到有義務保留現有的抽象，但由於它並不適用於每一個情況，所以他們修改代碼以接受參數……
- 循環直到代碼變得難以理解。
- 故事的這一部分以你出現，然後你的生活急轉直下。
這篇隨筆鼓勵程式員考慮抽象的長期可維護性，並認識到在正確的抽象邊界尚不明確時，暫時重複代碼可能更好。有時候，重複比錯誤的抽象危害更小。
程式設計中的通用性迷思
在程式設計時，考慮「不變性」——我們假設始終真實的特性是有幫助的。Patrick McKenzie 的隨筆程式員對名字的錯誤信念提醒我們，現實世界的數據很少符合我們整潔的假設。
這篇隨筆列出了許多程式員對名字做出的假設，這些假設並不普遍適用：
- 人們的名字在出生時就被指定。
- 好吧，也許不是在出生時，但至少接近出生的時候。
- 好吧，好吧，大概在出生一年內。
- 五年內？
- 你是在開玩笑吧？
這篇隨筆在程式設計社群中已成經典，因為它突出了我們的文化假設如何導致軟體中的錯誤和限制。認識到現實是混亂且多樣的，程式員可以構建更具包容性和穩健的系統。
重新思考技術招聘
招聘技術人才的過程因為著名的困難和低效。Thomas Ptacek 的隨筆招聘博文挑戰了傳統的招聘方法，提出了一種基於工作樣本而非簡歷和傳統面試的更有效的方法。
Ptacek 分享了一個關於一位意外新員工的啟示性故事：「Alex 的背景毫無提示這會發生。他有著沃爾特·懷特的簡歷，卻有著海森堡的能力。」這個經驗引導了一個啟示：「人才就在那里，但在簡歷上是找不到的。」
這篇隨筆有力地指出我們行業的標準招聘實踐是多麼的有缺陷：「我們的領域使用一個比閱讀雞腸更糟糕的過程來選拔工程師。」通過轉向直接衡量工作所需技能的工作樣本測試，公司可以識別出在傳統流程中可能被忽視的優秀人才。
產品導向的工程
僅僅擁有技術技能並不足以作為工程師獲得成功，特別是在創新公司。Gergely Orosz 的隨筆具有產品思維的工程師描述了讓工程師在創造讓用戶喜愛的產品時特別有效的特徵。
這些特徵包括：
- 對產品想法/意見積極主動
- 對業務、用戶行為和數據感興趣
- 對「為什麼」的好奇心和強烈興趣
- 良好的溝通和與非工程師良好的關係
- 提前提供產品/工程取捨
- 務實處理邊緣情況
- 快速的產品驗證周期
- 端到端產品功能擁有權
- 通過重複的學習周期擁有強大的產品直覺
這篇隨筆強調了最有效的工程師如何超越代碼本身，理解他們正在解決的問題和建造的產品的更廣泛背景。
為可拋棄性而設計
在寫易於刪除的代碼，而非易於擴展的代碼中，tef 挑戰了關於代碼重用和可維護性的常識觀念。與其專注於創建可以無限擴展的代碼，tef 建議可拋棄性應該是設計中的一個關鍵考慮因素。
「如果我們將『代碼行』視為『花費的行數』，那麼當我們刪除代碼行時，我們就在降低維護成本，」tef 寫道。「與其構建可重用軟體，我們應該嘗試建立可拋棄的軟體。」
這篇隨筆承認業務需求及其對代碼的影響：「業務邏輯是以永無止境的邊緣情況和快速而簡單的黑客為特點的代碼。這很正常。」這種觀點為追求完美的抽象提供了自由，並認識到探索性程式設計通常需要迭代而不是在第一次就做到完美。
抽象的現實
Joel Spolsky 的經典隨筆漏出抽象定律對於軟體中抽象的本質提供了基本的見解：它們不可避免會洩露。
以 TCP 為例，Spolsky 解釋了即使設計良好的抽象也無法完全隱藏其下的複雜性：「TCP 嘗試提供一個對底層不可靠網絡的完整抽象，但有時，網絡會通過抽象洩露出來，讓你感受到抽象無法完全保護你的東西。」
這導致了 Spolsky 所謂的漏出抽象定律：「所有非平凡的抽象，在某種程度上，都是洩露的。」這一見解幫助程式員理解為什麼即使在使用高級抽象時有時也需要深入低級細節。
性能對設計的影響
Nelson Elhage 的隨筆關於軟體性能的反思超越了更快軟體的明顯好處，探索了性能如何從根本上改變工具的使用方式。
「或許不太明顯的是，擁有更快的工具會改變用戶使用工具或執行任務的方式，」Elhage 觀察道。「用戶幾乎始終有多種策略可以追求目標——包括決定完全去做其他事情——而他們會選擇更頻繁地使用更快的工具。」
這種觀點突顯了性能不僅僅關乎效率；它關於啟用新的工作流程和可能性：「快速工具不僅僅讓用戶更快速完成任務；它們讓用戶可以以全新方式完成全新類型的任務。」
利用數據庫來確保正確性
Brandur Leach 的關於數據庫使用的系列作品，包括使用 ACID 和約束構建穩健系統，展示了如何利用關聯數據庫來確保複雜系統中的正確性。
「我想說服你，ACID 數據庫是當前存在的確保大生產系統的可維護性和數據正確性的重要工具之一，」Leach 寫道。他的隨筆展示了交易之類的特性如何用來實現例如 API 的冪等性這樣的模式。
在在 Postgres 中實現類似於 Stripe 的冪等性鍵中，Leach 解釋了冪等性如何使系統對失敗更具彈性：「冪等端點是指可以調用任意次數且保證副作用僅發生一次的端點。在一個可能偶爾崩潰或者連接中斷的客戶端和服務器混亂世界中，這對於使系統更具抵抗力以承受故障是巨大幫助。」
導航分布式系統
Jeff Hodges 的隨筆給年輕新手的分布式系統筆記為從事分布式系統工作的工程師提供了實用建議，而在現今的網絡世界中，這包括大多數軟體。
這篇隨筆提供了許多見解，包括：
- 分布式系統不同是因為它們經常失敗
- 在整個系統中實施反壓
- 尋找局部可用的方法
- 使用百分位數，而不是平均值
- 學會估算你的容量
- 特徵標誌是基礎設施推出的方法
- 明智地選擇 ID 空間
- 將緩存數據寫回持久存儲是不好的
- 提取服務
這些實用建議的集合為任何建立跨網絡運作系統的人提供了寶貴的指導。
端到端原則
J.H. Saltzer, D.P. Reed 和 D.D. Clark 的論文系統設計中的端到端論點引入了一個影響許多系統設計的原則，特別是網際網路。
端到端原則提出，「在低層次的系統放置功能可能是多餘的，或者與提供它們的成本相比價值不大。」該原則幫助設計人員決定系統的哪一層應該實現特定功能。
通過理解這一原則，工程師可以通過在適當的抽象水平上放置功能來創建更簡單、更高效的系統。
重新構想開發工具
Bret Victor 的演講Based on Principle展示了一種程式設計工具如何能提供更即時的反饋和與創作者所建設的東西更強的聯繫的願景。
Victor 主張：「創作者需要立即與其創造物相連接。」通過一系列演示，他展示了即時反饋循環如何改變創造過程並使程式設計更加直觀。
這個演講挑戰開發者重新思考他們如何與工具互動，並展望程式設計環境未來的新可能性。
為初學者理解程式設計
對於那些剛接觸程式設計或希望深化對這些概念的理解的人來說，這些隨筆為經驗豐富的開發者的思維過程提供了寶貴的見解。程式設計不僅關於理解原則和方法，而且還涉及熟悉特定語言或框架。
這裡強調的隨筆涵蓋了超越特定技術的程式設計基本方面：
- 心智模型：理解電腦是可以理解的，並且抽象有其局限性，有助於我們如何接近問題的框架。
- 決策制定：明智地選擇技術，理解抽象的取捨，知道何時應優先考慮可拋棄性而非可重用性是關鍵技能。
- 系統設計：如端到端原則和有關分布式系統的見解為創建穩健的軟體架構提供指導。
- 人為因素：認識到性能如何影響用戶行為、招聘實踐如何影響團隊組成以及產品導向的工程師如何創建更好的結果突顯了軟體開發的人性化要素。
通過研究這些隨筆及其內容的原則，新來者可以建立一種對程式設計更深層次的理解，這超越了語法和實施細節。這些隨筆中的見解代表了業界多年來的集體智慧。
結論：程式設計的不斷演進的知識基礎
這些隨筆僅代表程式設計中豐富智識傳統的一小部分。隨著這一領域的演變，新的隨筆將不斷湧現，挑戰現有的假設，並就持續存在的挑戰提供新的視角。
這些特定隨筆的價值在於它们著重於原則而非特定技術。儘管程式設計語言和框架不斷變化，但對系統設計、人類認知和工程選擇的見解在整個技術世代中保持相關性。
通過契合這些理念，所有級別的程式員都可以提高其對該領域的理解，並開發更有效的軟體創建方法。無論您剛開始您的程式設計旅程還是擁有多年的經驗，重溫這些基礎理念都能提供新的見解和對程式設計技藝的新視角。
留言
張貼留言