編程最頂的八句格言！

格言一：“All problems in computer science can be solved by another level of indirection”

解讀：“計算機科學中的所有問題都可以通過增加一個間接層來解決”，出自David Wheeler（劍橋大學計算機科學教授），這句話實在太頂，影響太深遠忍不住放在第一位。不管是軟件領域從設計模式到架構設計，還是硬件領域中例如存儲系統層次結構都可以見識到這句話的威力。當你遇到任何計算機相關問題感覺沒法解決時，首先想到的應該是這句話！

格言二：“Programming is like sex. One mistake and you have to support it for the rest of your life”

解讀：“編程就像性，一個錯誤必須終身承受”，出自Michael Sinz（微軟首席架構師），你的程序就像你的孩子，你總是細心呵護，并試圖給他最好的，終生不休。但人非圣賢，總會犯錯，關鍵在于從錯誤中學習提升自我，不放過任何一個從錯誤中恢復的機會。

格言三：“Simplicity is prerequisite for reliability”

解讀：“簡單是可靠的前提”，出自Edsger Dijkstra（荷蘭計算機科學家），對于復雜性代價的洞察，沒有人比荷蘭計算機科學先驅迪杰斯特拉更深刻。開始實踐寫代碼的時候，都傾向于搞得很復雜，否則的話會覺得“沒水平”，等真正成為有經驗的程序員后，驀然回首，簡單才是最可靠的，每個代碼構建塊都盡可能用最簡單的方式表達。

格言四：“It's harder to read code than to write it”

解讀：“讀代碼比寫代碼困難”，出自Joel Spolsky（StackOverflow合伙創始人）。代碼雖然是讓機器執行，但要靠人來維護，有經驗的程序員都有這樣的經歷，自己幾個月或者半年前些的代碼，翻出來的時候完全忘了什么邏輯，如果代碼難以閱讀，自己掉坑里都爬不起來，何況如果是別人寫的難以閱讀的代碼？這種代碼后續維護人員根本不敢對其修改或改進。好的程序員會編寫容易理解的代碼，只有愚蠢的人才只管機器是否能運行。

格言五：“Don't reapeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”

格言六：“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”

解讀：“計算機科學兩件最難的事情：緩存失效，命名和差一錯誤”，出自Leon Bambrick。記得某位大牛說過命名大概占據編程1/3時間，本來詞匯量就不大，真是活人要被命名憋死。緩存失效和差一錯誤，有經驗的程序員應該很容易體會其中的痛苦，無須贅述。

格言七：“It takes 3 times the effort to find and fix bugs in system test than when done by the developer. It takes 10 times the effort to find and fix bugs in the field than when done in system test. Therefore insist on unit tests by the developer”

解讀：“系統測試階段發現和修復bug需要付出的努力是開發者自己解決的3倍。而上線后付出的努力又是系統測試階段的10倍，因此，開發者一定要自己做單元測試”，出自Larry Bernstein，測試的重要性是毋庸置疑的，但是開發完了就上線，即使今天在一線大廠也時有發生，可以想象下其他公司這種情況更普遍。這樣做的直接后果是本來可以在開發階段比較容易搞定的問題，最后拖到線上爆發出來，導致工作量成數量級上升，看起來很快的開發節奏其實是最慢的方式，每天996的程序員需要看下是否能對號入座。編程是智力活動，一個人的精力是有限的，不可能一天24小時精力都高度集中，996意味著疲勞狀態下開展智力活動，更容易出現bug，對有經驗的程序員肯定有這種體會：線上發現的bug如果單拎出來，肯定會罵自己怎么會寫出這么白癡的代碼，但事實就是你寫的！在軟件開發的早期階段盡早發現問題，成本就會越低，更容易把自己打造成高質量軟件開發者的人設，所以單元測試盡早測，完備的測，否則你可能要審視下自己到底是在寫bug還是寫代碼？

格言八：“Good code is its own best documentation. As you're about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn't needed?’”

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。