三月份的開篇翻譯，把我自己給搞的不知所措，一看名字的時候，感覺對程式設計這方面挺有幫助的，5個著名的程式設計名言，以及解釋，吸引了我的興趣。
緊接着，看了第一段，作者篩選的引用至少有20年的曆史，那肯定是經久不衰，經典的Tips，很贊。看了幾個小标題，以及粗略的看了下重點關注的描述，我更加感興趣了。
但是，當我全身心投入到翻譯行動的時候，我把我自己坑了。整個翻譯，有點長，還有長句。不過不過，這不是問題，當你看完這篇，相信你肯定會引起共鳴，至于是什麼共鳴呢？肯定是基于你編碼能力的共鳴，帶着這份好奇，請你好好看下去吧。
我的翻譯能力有限，有時候還是借助于翻譯軟體來，是以翻譯不到之處，還請大家諒解，可以去看原文，和我多多交流。每周一篇翻譯，我堅持着我的堅持。
原文位址：
https://medium.com/young-coder/5-famous-programming-quotes-explained-4da607906c1
作者：Matthew MacDonald
5個著名的程式設計名言，解釋
通過了解這些永恒的見解，你将成為更好的開發人員。
成為一名優秀的程式員，就是讓你自己接受不斷學習的生活（活到老，學到老）。包括新功能、新語言、新工具、新架構等優秀的源頭--學習永不停息。但是，其實計算機科學也是一個令人驚訝的傳統領域，這是基于久經考驗的原則得出來的。我們已經添加了面向對象、現代硬體以及人工智能。然而，盡管發生了這麼多的變化，許多上一代人提出來的見解在今天仍然适用（這點和我們現在的名言警句類似）。
在這篇文章中，我剖析了一些我最喜歡的關于計算機科學的引用。我設定的唯一條件就是，每個優秀的引用必須至少有20年的曆史。因為古老的技術很快就會變得毫無用處，而我們程式設計祖先的古老戒律卻有更強的持久力。
- 關于Indirection
"計算機科學中的所有問題都可以通過另一種間接的方式來解決"。-- David Wheeler
這裡有一個很少被開發者願意解釋卻又經常被複用的compsci的引用。但這是我最喜歡的程式設計真理之一，因為它觸及了編碼的核心。
開始考慮Indirection的最簡單的方法是想像層次。例如，假設您有一個小項目，需要将元件A放入元件B：
兩個都是标準的元件，是以你不能破壞他們并更改他們的工作方式。你可以建構一個全新的元件，但這需要大量的工作和不必要的重複。一個更好的方式就是這兩個部分之間添加一層--一個适合于兩個元件并在它們之間進行轉化的擴充卡。（其實就是設計模式中的擴充卡模式）
現在，如果連接配接僅僅是添加一個新層來講不相容的部分組合在一起，這将是很好的，也确實很有用。但是圍繞問題進行建構來解決問題的想法是一個從底層一直延伸到頂層的概念。當你試圖将新的資料模型适配到舊的使用者接口時，你就會看到它；當你試圖将遺留應用安裝到一個新的web後端伺服器時，你就會看到它；當你需要綁定更好級别的特性（如日志和緩存）或協調更進階别的服務（如消息傳遞和事務）時，你就會看到它；在金字塔的頂端，你将會接觸到像機器學習（當你不能為你需要的行為編碼時，再寫一層代碼來幫你找出它）這樣的少數主題。
很多人會告訴你，程式設計就是用一種即使電腦小白也能了解的語言寫出明确的指令。但是大衛·惠勒的名言揭示了
更好的見解：好的程式設計是要爬上抽象的階梯才能到達最通用的解決方案。
相關引用：
Indirection是強大的，但是複雜性是有代價的。人們很少引用 Wheeler 關于Indirection的後續評論：
但通常會産生另一個問題 -- David Wheeler
從那時起，這一真理就一直讓程式員在商業上如日中天。
- 關于簡單
“簡單是可靠性的先決條件”。-- Edsger Dijkstra
不少明智的程式員警告我們不要使代碼過于複雜。但很少有人能比荷蘭計算機科學先驅 Edsger Dijkstra 更清楚地說明複雜性的成本。
這裡的見解是：你不會選擇簡單作為送給未來的禮物。你不做因為您正在期待機會重用您的代碼，或者因為您希望在代碼評審時讓它看起來更整潔，或者是因為您想使其更易于修改（盡管所有這些好處都是寶貴的！）。您這樣做因為簡單是一個先決條件。如果沒有簡單性，就永遠不可能有可以信賴的可靠代碼來開展業務或處理您的資料。
要接受Dijkstra的觀點，我們需要重新定義“好代碼”的含義。不是最短的代碼。它不一定是最快的代碼。絕對不是最聰明的代碼。可以信任的代碼。
相關引用：
保持代碼簡單的最佳方法之一就是記住少即是多。Dijkstra 提供了一個可幫助我們牢記這一點的名額：
“如果我們希望計算代碼行，則不應将它們視為‘産生的行’，而是看作‘花費的行’”。-- Edsger Dijkstra
- 關于可讀性和重寫
“讀代碼比寫代碼難”。-- Joel Spolsky
乍一看，這個引用來自軟體傳奇和StackOverflow共同建立者Joel Spolsky似乎是正确的，但看似膚淺。是的，代碼可能很密集，簡短而又冗長。這不僅僅是别人的代碼。如果您看一年前的工作，您可能需要一些時間來整理一下您曾經非常了解的邏輯。
但是Spolsky 的洞察力卻有所不同。您無法閱讀的代碼的危險不僅僅是顯而易見（很難對其進行更改和改進）。相反，更大的危險是複雜的代碼似乎比實際情況更糟。其實，嘗試了解别人已經寫好的代碼是如此之好，以至于您可能會被吸引犯 Spolsky所說的最嚴重的錯誤-決定從頭開重寫該代碼始。
并不是說重寫不能改善系統的體系結構。他們絕對可以。但這些改進付出了巨大的代價。他們重置測試和調試錯誤的時間固定，兩項活動比單純的編碼要花更長的時間。重寫很誘人因為它們是軟體開發中最常見的偏見之一：我們低估了做概念上簡單的事情的努力。這就是為什麼最終的5％項目需要50％的時間。簡單的事情可能會非常耗時！和解決您已經解決的問題相比似乎沒有比這容易的了。
是以，如果您不應該重寫所有内容以使其完美，那麼有什麼更好的解決方案？答案是讓每個開發人員都參與恒定大小的重構。這個為您提供小的，連續的代碼改進-真正有回報，并且風險很小。您可以在編碼的過程中提高可讀性。
相關引用：
如果您仍然不确定可讀性的重要性，Martin Fowler可以幫助您解決這一問題角度來看：
“任何人都可以編寫計算機可以了解的代碼。優秀的程式員寫的代碼人類都可以了解。” -- Martin Fowler
換句話說，程式員的工作不僅是寫代碼，更在于做有意義的事情。
- 關于重複
“不要重複自己。每一項知識必須有一個單一的，明确的，權威的系統中的表示形式。” — Andy Hunt and Dave Thomas
每個自重的程式員都知道重複是萬惡之源。如果您在不同的地方寫相同的東西，你在做額外的工作，測試和調試。更糟糕的是，您正在引入不一緻-例如，如果代碼的一部分已更新，而其他類似的代碼沒有同步更新。程式不一緻使您的程式存在偏差，而您存在偏差的程式不再是可行的解決方案。
但是，重複代碼并不是造成嚴重破壞的唯一地方。這個版本的著名的“請勿重複自己”（DRY）規則将無重複原則擴充為覆寫其他可能隐藏沖突之處。我們不再談論代碼重複。我們也在談論系統中的重複-系統具有代碼知識的許多不同方式。它們包括：
- 代碼聲明
- 代碼注釋
- 開發人員或客戶文檔
- 資料模式（例如，資料庫表）
- 其他規範，例如測試計劃，工作流程文檔和建構規則
所有這些層都可以彼此重疊。而當他們這樣做時，他們就有可能引入同一現實的不同版本。例如，如果文檔描述一種工作方式，但應用程式遵循另一種方式？誰擁有真相？如果資料庫表與代碼中的資料模型不比對怎麼辦？或者注釋描述了算法的操作，與實際的實施方式不符？每個系統都需要一個單一的、權威的，其他一切都必須高度統一。
順便說一下，競争版本的真相不僅是小規模項目中的問題或設計不良的代碼。最好的例子之一是随着XHTML和HTML5之間的鬥争。一個陣營認為規範是官方事實，需要對浏覽器進行更正以遵循它。另一派聲稱浏覽器行為是事實上的标準，因為這就是當設計師們寫網頁時已經想到了。最後，浏覽器版本的真相獲勝。從這一點上來說，HTML5的浏覽器就是這麼做的 -包括快捷鍵，他們允許和他們接受的錯誤.
相關引用：
代碼和注釋彼此沖突的可能性引發了關于注釋是否弊大于利的激烈辯論。極限程式設計的支援者公開懷疑：
“代碼永遠不會說謊；代碼注釋有時會。” - Ron Jeffries
- 關于難題
“計算機隻有兩件事科學：緩存失效以及命名事物。” -- Phil Karlton
乍一看，這句話似乎很有趣，但卻是普通的程式設計笑話。聽起來很困難的内容（緩存無效）與聽起來很輕松（為事物命名）的事物可以立即關聯。每一個程式員投入了數小時的工作來解決一個荒謬的瑣碎問題，例如參數傳遞順序錯誤或大小寫不一緻的變量（感謝JavaScript）。隻要人類需要與機器合作完成任務，程式設計将成為進階系統規劃和瑣碎輸入錯誤的混搭。
但是，如果您再看一看Phil Karlton的引用，還有更多需要解決的問題。命名事情并不難，因為程式員的生活經常因小小的頭痛而毀了。這也是因為命名問題實際上是每個程式員最關心的重要工作：軟體設計。換句話說，您如何編寫清晰的代碼，幹淨，一緻嗎？
有很多方法可以使命名錯誤。我們都看到過以變量命名的資料類型（myString，obj），縮寫（用于産品目錄的pc），一些瑣碎的實作細節（swappable_name，formUserInput），甚至什麼都沒有（ret_value，tempArray）。容易陷入基于以下方式命名變量的陷阱您當時正在使用它做什麼，而不是其中包含什麼。布爾值是特别棘手的-當 progress 标記進度開始，表明您需要在使用者界面中顯示進度資訊，或完全标記某些内容不同？
但是變量名僅僅是開始。命名類提出了如何将代碼分成獨立部分的問題。命名 public 成員将影響您的工作方式顯示允許應用程式的一部分與另一部分互動的界面。鎖定這些名稱不僅描述了一段代碼可以做什麼，而且确定它将做什麼。
相關引用：
“計算機科學有兩件事：緩存失效，事物命名和一對一錯誤。” -- Leon Bambrick
喜歡這個清單并想提高自己的技能？檢視《5本書可以幫助您成為更好的程式員》這篇我下周在進行翻譯。
結語
很高興，你和我一樣堅持看到了最後，是不是對自己程式設計過程中有很多想改變的地方呢？比如簡單行，可讀性，DRY原則，是不是讓你銘記在心，還有最後說的緩存失效很難，命名很簡單的錯覺。
我感受很深的就是DRY原則，以及命名很簡單這兩點。因為我維護的程式裡，真的有重複操作的代碼，改一個地方，忘記改另一個地方，結果經常被測試怼；讓我有想重構的沖動，前幾天剛把這個老大難給搞定。還有命名，總不能幾個月隻會自己看這個命名，卻不知道什麼意思吧。
最後作者留了一個菜單，5本書幫你成為更好的程式員，下周的素材找好了，約嗎？
作者：躍哥，前菊廠Android開發，現遊戲公司Java主程，奔跑中的技術人！