不多有人會告訴你的5個編程名言，安排！

經過理解這些永恆的看法，你將成爲更好的開發人員。

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

在這篇文章中，我剖析了一些我最喜歡的關於計算機科學的引用。我設置的惟一條件就是，每一個優秀的引用必須至少有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 成員將影響您的工做方式顯示容許應用程序的一部分與另外一部分交互的界面。鎖定這些名稱不只描述了一段代碼能夠作什麼，並且肯定它將作什麼。

相關引用：

「計算機科學有兩件事：緩存失效，事物命名和一對一錯誤。」——Leon Bambrick

結語

很高興，你和我同樣堅持看到了最後，是否是對本身編程過程當中有不少想改變的地方呢？好比簡單行，可讀性，DRY原則，是否是讓你銘記在心，還有最後說的緩存失效很難，命名很簡單的錯覺。