很少有人會告訴你的5個編程名言，安排

piyanat 2020-05-10

展開全文

通過理解這些永恒的見解，你將成為更好的開發人員。

成為一名優秀的程序員，就是讓你自己接受不斷學習的生活（活到老，學到老）。包括新功能、新語言、新工具、新框架等優秀的源頭——學習永不停息。但是，其實計算機科學也是一個令人驚訝的傳統領域，這是基于久經考驗的原則得出來的。我們已經添加了面向對象、現代硬件以及人工智能。然而，盡管發生了這么多的變化，許多上一代人提出來的見解在今天仍然適用（這點和我們現在的名言警句類似）。

在這篇文章中，我剖析了一些我最喜歡的關于計算機科學的引用。我設置的唯一條件就是，每個優秀的引用必須至少有20年的歷史。因為古老的技術很快就會變得毫無用處，而我們編程祖先的古老戒律卻有更強的持久力。

1. 關于Indirection

'計算機科學中的所有問題都可以通過另一種間接的方式來解決'。——David Wheeler

這里有一個很少被開發者愿意解釋卻又經常被復用的compsci的引用。但這是我最喜歡的編程真理之一，因為它觸及了編碼的核心。

開始考慮Indirection的最簡單的方法是想像層次。例如，假設您有一個小項目，需要將組件A放入組件B：

兩個都是標準的組件，因此你不能破壞他們并更改他們的工作方式。你可以構建一個全新的組件，但這需要大量的工作和不必要的重復。一個更好的方式就是這兩個部分之間添加一層——一個適合于兩個組件并在它們之間進行轉化的適配器。（其實就是設計模式中的適配器模式）

現在，如果Indirection僅僅是添加一個新層來講不兼容的部分組合在一起，這將是很好的，也確實很有用。但是圍繞問題進行構建來解決問題的想法是一個從底層一直延伸到頂層的概念。當你試圖將新的數據模型適配到舊的用戶接口時，你就會看到它；當你試圖將遺留應用安裝到一個新的web后端服務器時，你就會看到它；當你需要綁定更好級別的特性（如日志和緩存）或協調更高級別的服務（如消息傳遞和事務）時，你就會看到它；在金字塔的頂端，你將會接觸到像機器學習（當你不能為你需要的行為編碼時，再寫一層代碼來幫你找出它）這樣的少數主題。

很多人會告訴你，編程就是用一種即使電腦小白也能理解的語言寫出明確的指令。但是大衛·惠勒的名言揭示了更好的見解：好的編程是要爬上抽象的階梯才能到達最通用的解決方案。

相關引用：

間接是強大的，但是復雜性是有代價的。人們很少引用惠勒關于間接的后續評論：

但通常會產生另一個問題——David Wheeler

從那時起，這一真理就一直讓程序員在商業上如日中天。

2. 關于簡單

“簡單是可靠性的先決條件”。——Edsger Dijkstra

不少明智的程序員警告我們不要使代碼過于復雜。但很少有人能比荷蘭計算機科學先驅 Edsger Dijkstra 更清楚地說明復雜性的成本。

這里的見解是：你不會選擇簡單作為送給未來的禮物。你不做因為您正在期待機會重用您的代碼，或者因為您希望在代碼評審時讓它看起來更整潔，或者是因為您想使其更易于修改（盡管所有這些好處都是寶貴的！）。您這樣做因為簡單是一個先決條件。如果沒有簡單性，就永遠不可能有可以信賴的可靠代碼來開展業務或處理您的數據。

要接受Dijkstra的觀點，我們需要重新定義“好代碼”的含義。不是最短的代碼。它不一定是最快的代碼。絕對不是最聰明的代碼。可以信任的代碼。

相關引用：

保持代碼簡單的最佳方法之一就是記住少即是多。Dijkstra 提供了一個可幫助我們牢記這一點的指標：

“如果我們希望計算代碼行，則不應將它們視為‘產生的行’，而是看作‘花費的行’”。——Edsger Dijkstra

3. 關于可讀性和重寫

“讀代碼比寫代碼難”。——Joel Spolsky

乍一看，這個引用來自軟件傳奇和StackOverflow共同創建者Joel Spolsky似乎是正確的，但看似膚淺。是的，代碼可能很密集，簡短而又冗長。這不僅僅是別人的代碼。如果您看一年前的工作，您可能需要一些時間來整理一下您曾經非常了解的邏輯。

但是Spolsky 的洞察力卻有所不同。您無法閱讀的代碼的危險不僅僅是顯而易見（很難對其進行更改和改進）。相反，更大的危險是復雜的代碼似乎比實際情況更糟。其實，嘗試了解別人已經寫好的代碼是如此之好，以至于您可能會被吸引犯 Spolsky所說的最嚴重的錯誤-決定從頭開重寫該代碼始。

并不是說重寫不能改善系統的體系結構。他們絕對可以。但這些改進付出了巨大的代價。他們重置測試和調試錯誤的時間固定，兩項活動比單純的編碼要花更長的時間。重寫很誘人因為它們是軟件開發中最常見的偏見之一：我們低估了做概念上簡單的事情的努力。這就是為什么最終的5％項目需要50％的時間。簡單的事情可能會非常耗時！和解決您已經解決的問題相比似乎沒有比這容易的了。

因此，如果您不應該重寫所有內容以使其完美，那么有什么更好的解決方案？答案是讓每個開發人員都參與恒定大小的重構。這個為您提供小的，連續的代碼改進-真正有回報，并且風險很小。您可以在編碼的過程中提高可讀性。

相關引用：

如果您仍然不確定可讀性的重要性，Martin Fowler可以幫助您解決這一問題角度來看：

“任何人都可以編寫計算機可以理解的代碼。優秀的程序員寫的代碼人類都可以理解。”——Martin Fowler

換句話說，程序員的工作不僅是寫代碼，更在于做有意義的事情。

4. 關于重復

“不要重復自己。每一項知識必須有一個單一的，明確的，權威的系統中的表示形式。”——Andy Hunt and Dave Thomas

每個自重的程序員都知道重復是萬惡之源。如果您在不同的地方寫相同的東西，你在做額外的工作，測試和調試。更糟糕的是，您正在引入不一致-例如，如果代碼的一部分已更新，而其他類似的代碼沒有同步更新。程序不一致使您的程序存在偏差，而您存在偏差的程序不再是可行的解決方案。

但是，重復代碼并不是造成嚴重破壞的唯一地方。這個版本的著名的“請勿重復自己”（DRY）規則將無重復原則擴展為覆蓋其他可能隱藏矛盾之處。我們不再談論代碼重復。我們也在談論系統中的重復-系統具有代碼知識的許多不同方式。它們包括：

代碼聲明
代碼注釋
開發人員或客戶文檔
數據模式（例如，數據庫表）
其他規范，例如測試計劃，工作流程文檔和構建規則

所有這些層都可以彼此重疊。而當他們這樣做時，他們就有可能引入同一現實的不同版本。例如，如果文檔描述一種工作方式，但應用程序遵循另一種方式？誰擁有真相？如果數據庫表與代碼中的數據模型不匹配怎么辦？或者注釋描述了算法的操作，與實際的實施方式不符？每個系統都需要一個單一的、權威的，其他一切都必須高度統一。

順便說一下，競爭版本的真相不僅是小規模項目中的問題或設計不良的代碼。最好的例子之一是隨著XHTML和HTML5之間的斗爭。一個陣營認為規范是官方事實，需要對瀏覽器進行更正以遵循它。另一派聲稱瀏覽器行為是事實上的標準，因為這就是當設計師們寫網頁時已經想到了。最后，瀏覽器版本的真相獲勝。從這一點上來說，HTML5的瀏覽器就是這么做的 -包括快捷鍵，他們允許和他們接受的錯誤.

相關引用：

代碼和注釋彼此矛盾的可能性引發了關于注釋是否弊大于利的激烈辯論。極限編程的支持者公開懷疑：

“代碼永遠不會說謊；代碼注釋有時會。”——Ron Jeffries

5. 關于難題

“計算機只有兩件事科學：緩存失效以及命名事物。”——Phil Karlton

乍一看，這句話似乎很有趣，但卻是普通的編程笑話。聽起來很困難的內容（緩存無效）與聽起來很輕松（為事物命名）的事物可以立即關聯。每一個程序員投入了數小時的工作來解決一個荒謬的瑣碎問題，例如參數傳遞順序錯誤或大小寫不一致的變量（感謝JavaScript）。只要人類需要與機器合作完成任務，編程將成為高級系統規劃和瑣碎輸入錯誤的混搭。

但是，如果您再看一看Phil Karlton的引用，還有更多需要解決的問題。命名事情并不難，因為程序員的生活經常因小小的頭痛而毀了。這也是因為命名問題實際上是每個程序員最關心的重要工作：軟件設計。換句話說，您如何編寫清晰的代碼，干凈，一致嗎？

有很多方法可以使命名錯誤。我們都看到過以變量命名的數據類型（myString，obj），縮寫（用于產品目錄的pc），一些瑣碎的實現細節（swappable_name，formUserInput），甚至什么都沒有（ret_value，tempArray）。容易陷入基于以下方式命名變量的陷阱您當時正在使用它做什么，而不是其中包含什么。布爾值是特別棘手的-當 progress 標記進度開始，表明您需要在用戶界面中顯示進度信息，或完全標記某些內容不同？

但是變量名僅僅是開始。命名類提出了如何將代碼分成獨立部分的問題。命名 public 成員將影響您的工作方式顯示允許應用程序的一部分與另一部分交互的界面。鎖定這些名稱不僅描述了一段代碼可以做什么，而且確定它將做什么。

相關引用：