2. 程式人生 > >每個程式設計師應該瞭解的97件事情

每個程式設計師應該瞭解的97件事情

阿新 • • 發佈：2019-01-12
原文：http://dearymz.blog.163.com/blog/static/205657420139243750104/
正文之前
  1. 熟知軟體開發的人都知道這個行業裡充滿了一次次悲壯的失敗，每一座成功專案的豐碑下都埋葬著無數同類型的失敗專案。大多數軟體專案都像是一次典型的死亡行軍
  2. 加班是一種習慣，並會逐漸產生依賴
  3. 程式設計遠遠超過程式本身的概念
程式設計師應該知道的97件事
  1. 謹慎行動
    1. 技術債務就像一筆貸款。在短期內，你能從中得到好處，但是，在清償之前，你要付出利息。程式碼裡的捷徑使得新功能更難於加入，也會影響到程式碼重構。它們是軟體缺陷和失敗測試用例的滋生地，放任它們的時間越長，情況就會越糟糕。
    2. 往往是情況不可收拾時，你才不得不對它們進行修正，而那時你已沒有足夠的時間，也承擔不起由此帶來的風險
    3. 必須時刻追蹤技術債務，儘快的或者當情況急劇惡化的時候，立即將其償還。每當你迫不得已欠下了技術債務，就要立即記錄到人物卡上或者等級到問題追蹤系統裡，以保證其不會被遺忘
  2. 函數語言程式設計原則的應用
    1. 函數語言程式設計能極大地提高你的程式碼質量
    2. 引用透明性：函式不管在何時何地被呼叫，都保持一致的行為，同樣的輸入得到同樣的輸出結果
  3. 試問自己“使用者會怎麼做”（你不能算是使用者）
    1. 我們都愛假設別人的心思跟我們一樣，但事實上不是這回事。心理學上把這種心理狀態叫做虛假同感偏差(false consensus bias)。當人們的想法和行為跟我們不同時，我們很可能會（在潛意識裡）將他們歸位“能力低下”的人
    2. 使用者卡住的時候，他們會縮小他們的注意力範圍，於是更難以看到在螢幕其他區域上顯示的解決方法。因為使用者注意力範圍縮小，使用tool tip的效果勝過點選幫助選單
    3. 使用者都傾向於能用就好。他們一旦找到一種可用的方法，就會一直用下去，不管它有多麼費勁。因此，提供一條顯而易見的操作途徑，要好過提供兩三條捷徑
  4. 編碼標準的自動化
    1. 編碼標準應該是動態的，不是一成不變的。隨著專案的進展，專案需求的改變，一些在剛開始時顯得靈活的標準可能在幾個月後會變得不夠靈活
  5. 美在於簡單
    1. 風格之美、和諧、優雅及優美的節奏盡在於簡單——柏拉圖
    2. 優美的程式碼有許多共同的屬性，首要的一點就是簡單。一個應用或一個系統無論有多麼複雜，其中每個單獨的組成部門都保持著它的間接性。
    3. 無論經過多少時間，乾淨、簡單、可測試的程式碼保證了系統的可維護性，也確保了系統在整個生命週期裡能快速開發升級
    4. 美來自於簡單，亦存在於簡單
  6. 在你重構之前
    1. 重構程式碼的最佳起點就是清理已有的基礎程式碼和基於這些程式碼寫的測試
      1. 我們都覺得自己可以比原有系統做得更好，這是因為我們沒有向原有系統中的錯誤學習
    2. 避開重寫一切的誘惑
      1. 儘可能多的重用程式碼是最好的選擇，無論程式碼是多麼的醜陋，畢竟它已經被測試過了，也被審查過了
      2. 拋棄舊程式碼——尤其是存在於產品中的程式碼——也意味著拋棄了經年累月測試並實戰過的程式碼，以及你還未知曉的周邊程式碼和bug補丁。這會浪費大量的時間、精力和多年積累下來的知識
    3. 逐步增加的小改動勝過一次性的大改動
    4. 在每次迭代之後，要確保已有的測試使用者都已通過
      1. 假如已有的測試用例還沒能覆蓋到你所做的修改部分，那就增加新的測試用例
    5. 個人好惡和利己主義不能參雜到開發中來
      1. 如果程式碼的風格或結構不符合你的個人喜好，你也不能把這當作程式碼重構的正當理由。即使你覺得自己可以比上一個程式設計師做得更好，也不能將它作為重構的理由。
    6. 新技術不是重構的充分理由
      1. 關於重構的最差勁的理由之一就是當前程式碼跟我們目前擁有的很酷的技術相比已經遠遠落後了，我們相信用新的語言或框架來完成這些功能會更加優雅。
      2. 除非成本效益分析結果表明這種新的語言或框架能在功能性、可維護性或生產力上會有顯著的提升，否則，最好還是棄之不用
    7. 要記住人總是會犯錯誤的
      1. 重構不能一直保證新程式碼會超過——或相當於——原先的程式碼
  7. 謹防共享
    1. 建立共享的程式碼庫之前，應該仔細檢查上下文環境
  8. 童子軍規則
    1. 若各團隊能把系統當成一個整體來維護，不再“各人自掃門前雪”，我們將看到軟體系統裡無可挽回的退化局面會終結，而且會逐漸變得更好
    2. 把程式碼搞得一團糟的行為也應該像社會上亂丟垃圾行為一樣不受待見，因為是該做的卻沒有做到的行為
    3. 團隊要相互幫助，相互清理程式碼，這對每一個人都有好處，而不僅僅是他們自己
  9. 在責備別人之前先檢查自己的程式碼
    1. 假如使用的工具是一個被廣泛使用的、成熟的，不同技術領域都在用的產品，那就幾乎沒有理由去懷疑它的品質
    2. 如果其他人報告說有問題，而你卻無法重現時，那就走過去看看他們到底是怎麼操作的
  10. 謹慎選擇你的工具
    1. 現在的應用程式很少從零開始構建的
    2. 從小範圍開始，只採用相對必需的工具
  11. 領域語言裡的程式碼
  12. 程式碼就是設計
    1. 大幅削減建造成本，導致的結果卻是質量惡化
    2. 軟體設計只有通過了一系列嚴格的測試驗證之後才能算完成
    3. 我們的希望在於改良的程式設計語言及設計的最佳實踐
    4. 偉大的設計是由偉大的設計者作出的，他們窮盡一生精通了該門技藝
  13. 關於程式碼佈局的麻煩事
    1. 易於檢索
    2. 清晰的佈局
    3. 緊湊格式
  14. 程式碼審查
    1. 程式碼審查能提供改嗎質量，降低差錯率。一個組織很需要這樣一個硬性的、正式的過程
    2. 程式碼審查的目的不僅僅是簡單的更正程式碼錯誤，其目的應該是共享知識、建立統一的編碼指導標準
    3. 程式碼審查的時候態度要溫和，確保評語是有建設性的，不是刻薄的
    4. 在程式碼審查會議上，對程式碼格式應該不做評論
    5. 主要著眼於在團隊成員之間分享知識，拋開諷刺性的評語
  15. 編寫程式碼的理由
    1. 避免使用可更改的全域性變數，因為這會讓所有使用它們的程式碼段產生依賴
  16. 對註釋的一個註釋
  17. 程式碼說不清，註釋來補充
    1. 無法給程式碼增加價值的註釋就是噪音。那些只會 模仿程式碼的註釋無法給讀者提供更多的資訊
    2. 應該像對待程式碼一樣對待註釋。每一段註釋應該為讀者注入一些價值，否則純粹就是浪費，還不如刪除，或者乾脆重寫
  18. 不斷學習
    1. 你需要為你自己的教育負起責任
    2. 儘量為自己找到一個導師。如果自己就是最厲害的傢伙，那會阻礙你的修習之路。雖然你可以從其他人身上學到點什麼，但是，在那些更聰明、經驗更豐富的人身上，你能學到更多。如果找不到導師，就換一個地方
    3. 每年學習一門新的語言，至少要學用一門新的技術或工具。這可以幫助你拓寬新思路，充實你當前的技術儲備
  19. 易用不是一種能力
    1. 好的API要遵循一致的抽象層次，並展現出它的一致性和對稱性，最終組成一份表達充分的詞彙表。
    2. API應該提供一種表達充分的語言，給予上層一份豐富的詞彙表，讓它能據此請求和回覆那些有用的問題
    3. 易用並且經過深思熟慮的API詞彙表可以導致上層使用富有表現力的、易於理解的程式碼
  20. 早部署，常部署
    1. 釋出工程師(Release Engineer)
    2. 定期在一個乾淨的環境中執行和測試安裝過程，可以讓你檢查出程式碼中那些基於開發或測試環境所做的假定是否合理
    3. 把部署放到最後意味著那些圍繞著部署假定的程式碼會變得更加複雜
    4. 所有權衡事項宜早不宜遲
  21. 區分業務異常和技術異常
    1. 由於領域邏輯的原因無法完成呼叫而產生的業務異常，是契約的一部分，丟擲異常只是按原路徑返回錯誤的一種替代方式，客戶端應該知道並且隨時準備處理它
  22. 有針對性的勤加練習
    1. 有針對性的勤加練習就是通過執行一項任務來提高自身的能力，關乎技巧和技術
    2. 做有針對性的練習就是為了精通這項任務，並不是完成任務
    3. 有償開發的首要目標是完成一個產品，而有針對性的練習的首要目標是提高你的水平。兩者是不一樣的
    4. 精英執行者也至少需要10000個小時的有針對性的聯絡才能成為專家
    5. 偉大在很大程度上就是有意識選擇的結果
    6. 達到專家水平的主要因素就是花時間去做帶有針對性的練習
    7. 有針對性的練習意味著多練習你不擅長的東西
    8. 學習改變你的東西，學習改變你行為的東西。祝你好運！
  23. 領域特定語言
  24. 不要怕搞砸
    1. 熟練的外科醫生都知道為了手術必須要開幾道切口，但是，她也知道這切口都是臨時的，會癒合的
    2. 對於改變的麻痺式恐懼在開始時就會讓你的專案陷入到這種投鼠忌器的狀態
    3. 作為一個外科醫生，為了給痊癒騰出空間，她一點都不害怕切除壞死組織
  25. 不要在你的測試程式碼裡裝可愛
    1. 在你的程式碼裡寫入文字的時候，無論是註釋、日誌、對話方塊或者測試資料，都要問一下自己如果這些公開出去的話會怎麼樣。這樣會讓你少臉紅幾次
  26. 不要忽略那個錯誤
    1. 不顧紅燈亮起，繼續前行，結果只會招致更大的損失。要在時機初現的時候就動手，把損失較少到最小
  27. 不要只學習語言，還要了解它的文化內涵
  28. 不要把程式釘死在老地方
  29. 不要指望“魔法會在此發生”
    1. 沒有開發經驗的經理會認為程式設計師做的事情很簡單，而沒有管理經驗的程式設計師也認為經理所做的事情很簡單
  30. 不要重複你自己
    1. 應用裡的每一行程式碼都會被維護到，它們就是未來bug的潛在來源
    2. DRY的要求是“在一個系統內，每一塊知識必須有一個單一的、明確的、權威的表示”
    3. 將重複的過程呼叫自動化
    4. 凡是有痛苦的手工過程存在的地方，都可以使用自動化，手工過程本來就應該被自動化和標準化
  31. 別碰那些程式碼！
    1. 開發人員——甚至是高階開發人員的訪問許可權都應該不能超越開發伺服器
    2. 如同開發人員不需要訪問開發伺服器之外的任何伺服器一樣，QA團隊和使用者也不需要接觸開發伺服器上的任何東西
    3. 釋出經理是唯一能訪問這兩臺伺服器的人
    4. 無論在哪種情況下——從根本上說，就是永遠不要讓開發人員有訪問產品伺服器的許可權
    5. 如果程式碼有問題，產品伺服器不是修復它的地方
  32. 封裝行為，而不僅僅是狀態
  33. 浮點數不是真正的數
    1. 浮點數的精度是有限的，是可以窮盡的。甚至在分佈範圍內的間隔也不是均勻的
  34. 開源助你實現雄心壯志
    1. 通過給別人的軟體編寫測試程式碼，能讓你學得更快，超過軟體開發裡其他任何一個活動
  35. API設計的黃金法則
    1. 鎖定API：可以試著把絕大多數的類和方法都表上final，以此來阻止使用者的過載或程式碼的濫用，避免未來你在更改選擇時受到約束
    2. 單元測試是實踐中極端重要的一部分
    3. API設計的黃金法則：只為你開發的API編寫測試程式碼是不夠的，你還必須給使用API的程式碼編寫單元測試
  36. 高手神話
    1. 如果某人看上去像是個高手，那是因為他擁有多年的學習和思維精煉過程的積累。“高手”往簡單上講就是一個有著無窮好奇心的聰明人
    2. 我們不需要高手，我們需要能幫助其他人在他們領域裡成為專家的專家
  37. 如何使用bug跟蹤器
    1. 一個好的bug報告需要具備三樣東西：
      1. 如果重現該bug，儘可能準確的描述，間隔多久後bug會再出現一次
      2. 本應該發生什麼，至少按你自己的見解來說
      3. 實際上發生了什麼，或者至少是你記錄到的儘可能多的資訊
    2. bug不是工作的標準單元，不能像一行行程式碼那樣精確地衡量著你的努力。（其實程式碼行也只是粗略衡量）
  38. 程式碼的去蕪存菁
    1. 通過刪除基礎程式碼中那些令人不快的功能特性，降低了全域性程式碼熵的水平
    2. 編寫程式碼是因為他們增加價值，而不是取悅你自己
    3. 如果你現在不需要，那現在就不要寫
    4. 額外程式碼的編寫和維護總是會花更長的時間。一團小小的額外程式碼“雪球”隨著時間的推移會變成一項龐大的需要維護工作
    5. 程式設計師發明了額外的需求，既不記錄在文件裡，也沒經過討論確認這個額外功能特性。這需求實際上就是捏造出來的。
    6. 系統需求不是程式設計師設定的，而是客戶要做的
  39. 安裝我吧
    1. 記住，客戶也下載了競爭對手的框架。你知道的，競爭對手總是在論壇裡宣稱他們的框架比你的好很多
  40. 程序間通訊對應用程式響應的影響
    1. 許多效能管理著作仍然執著於資料結構和演算法，這些因素在某些情況下是會起一些作用，但是在現代多層企業應用中並不處於主導地位
    2. 響應時間極大地依賴於對刺激作出響應的遠端程序間通訊的數量。
    3. 用於響應刺激的遠端IPC數目越多，響應時間就會越大。如何減少？
      1. 吝嗇原則，優化程序間的介面，只為互動過程準備最小數量的正確的資料
      2. 在可能的情況下，並行執行程序間通訊，這樣總的響應時間會主要取決於時延最長的IPC
      3. 快取前次IPC的結果，將來的IPC就可能不用再執行，直接用命中的本地快取來代替
  41. 保持構建的整潔
    1. 忽略事情也是腦力勞動
    2. 來自於構建的警告是有用的。你要在開始注意到它們的時候就著手清除，不要等到最後“大掃除”的時候再去做
    3. 讓構建保持乾淨，不只是消滅編譯錯誤或者測試失敗：警告資訊也是“程式碼衛生”裡重要且關鍵的一部分
  42. 知道如何使用命令列工具
    1. 設計良好的IDE不過就是一套命令列工具的圖形化前端
  43. 通曉兩門以上程式語言
    1. 一個程式設計師的程式設計技巧跟他能得心應手處置的不同程式設計範例數目直接相關
    2. 只懂得一種語言的程式設計師會被那種語言禁錮住她的思想
    3. 程式設計正規化：過程式、面向物件、函式式、邏輯型、資料流……
    4. 每個程式設計師最好能在兩種不同的正規化下有熟練的程式設計技能，理想一點就是掌握五種程式設計正規化
    5. 程式設計師應該對學習新語言始終保持著興趣，特別是對於不熟悉的正規化
  44. 瞭解你的IDE
  45. 瞭解你的侷限性
    1. 你的資源是有限的。你只有這麼點時間、這點錢去做你的事情，包括還要花錢花時間讓你的知識、技能和工具跟上時代。所以，你的工作要如此投入、如此快速、如此靈活、如此持久。你的工具也就這點威力，你的目標機器也就這點功率。因此，你不得不考慮一下你有限的資源
    2. 對於小陣列，線性查詢很有競爭力
  46. 知道你下次提交的內容
    1. 程式碼要在頭腦裡有著清晰的意圖和有限且可達的目標
    2. 知道你下次所要提交的東西。如果你無法完成，就丟棄掉更改，然後按照你已有的理解，定義出一項你確信能完成的新任務。只要有需要也要做一些投機試驗，但是不要在無意之中陷入到投機模式中。
    3. 千萬不要把猜想得到的東西放入程式碼庫裡。
  47. 大型、相關性的資料屬於資料庫
  48. 學習外語
    1. 付出總會有回報，時機早晚會來
    2. 在今天，跟簡單的程式設計實用工藝相比，大型專案更像是社會性的事業
    3. 懂另外一門語言，就是擁有了另一個靈魂
    4. 要懂得什麼時候傾聽，而不是交談，要知道多數語言是沒有文字的
    5. 對於不可言說的，必須保持沉默——Ludwig Wittgenstein
  49. 要學會估算
    1. 估算就是對價值、數值、質量及其擴充套件專案作出近似的計算和判斷。估算是基於實際資料和以往經驗的實際衡量——在計算的時候不能讓希望和願望摻雜進來。估算是一個近似值，估算是不可能精確地
    2. 目標是對所要達到的商業目標的陳述
    3. 承諾就是答應在某個日期或者某個事件發生之時，提交否和某個質量水平的指定功能
    4. 估算、目標和承諾三者是相互獨立的，但是，目標和承諾要基於合理的估算。
    5. 軟體估算的首要用途不是為了預測一個專案的產出成果，而是為了測定一個專案的目標是否足夠現實，從而使專案處於控制之下實現這些目標。
    6. 估算的用途是為了讓適當的專案管理和計劃成為可能，允許專案的各利益相關方基於現實目標作出承諾
  50. 學著說“Hello, World”
  51. 讓你的專案能表達它自己
  52. 連結器並不神祕
    1. 要想知道可執行檔案為什麼是這個大小，可以看一下連結器選擇生成的map檔案。map檔案就是一張包含了可執行檔案裡所有符號及它們地址的列表。它告訴你庫裡的哪些模組連結進來了，以及每個模組的大小。由此你就能看出可執行檔案體積膨脹是從哪裡發源的
  53. 臨時解決方案的壽命
    1. 當系統裡容納了太多臨時解決方案的時候，它的熵或者或內部複雜度會隨之增加，而它的可維護性卻在降低
    2. 征服臨時解決方案的最佳途徑是讓它們變得多餘，提供一個更優雅、更有用的解決方案
  54. 使介面易於正確使用，難於錯誤使用
    1. 好的介面是易於正確使用，難以錯誤使用
    2. 易用的介面看上去很自然，因為它們讓你做你想做的事情
    3. 要記住介面的存在是為了方便使用者，而不是實現者
  55. 讓不可見的更加顯眼
    1. 修復bug不能算是有進展。除錯就是一種浪費。只有讓浪費的時間暴露在關注之下，這樣你才會認識到什麼導致了時間的浪費，並開始反省當初應該細心一點
    2. 如果你的專案還處於可跟蹤的狀態之下，但僅僅一個星期之後，你卻發現進度上已經延遲六個月了，這時你碰到問題了——最大的問題可能不是它長達六個月的延遲，而是有股隱形的力量已經強大到掩蓋了專案延遲六個月這個事實
    3. 單元測試的編寫提供了該程式碼單元便於做單元測試的證據。它有助於揭示程式碼存在（或不存在）你希望它能表現出的品質，例如低耦合和高內聚
    4. 單元測試的執行提供了該程式碼行為的證據。它有助於揭示程式碼擁有（或不擁有）你所希望的它在執行時能表現出的品質，例如健壯性和正確性
    5. 可見性能讓人充滿信心，讓人覺得進展是真實的，而不是虛幻的，是有備而來的，而不是憑空想象的，是可以重複的，而不是偶爾為之的
  56. 在並行系統中使用訊息傳遞可獲得更好的伸縮性
    1. 人們一次次碰到的併發問題幾乎都跟易變的共享記憶體有關係
    2. 要麼放棄併發，要麼放棄共享記憶體
    3. 資料流系統：在一個數據流系統裡，沒有明確的程式設計控制流，只有一系列有向圖的運算元，用資料路徑相連線。建立起關係後，再把資料“灌”入系統
    4. 要想充分駕馭計算機硬體內建的並行能力，使用訊息傳遞是一條比共享記憶體程式設計更為成功的路徑
  57. 帶給未來的訊息
    1. 每一行程式碼都是帶給未來某個人的訊息
  58. 錯失採用多型的機會
  59. 奇聞軼事：測試人員是你的朋友
  60. 二進位制檔案僅此一份
  61. 有程式碼有真相
  62. 擁有（及重構）構建指令碼
    1. 構建指令碼也是程式碼。它們如此重要以至於你最好自己親自來做
  63. 結對程式設計，感受流程
    1. 在任務輪轉到另一個結對之前，你不必非把它結束掉不可
    2. 有了結對程式設計、合適的結對及任務的輪轉方式，新來者會很快認識程式碼和其他團隊成員
  64. 特定領域型別勝過原始型別
    1. 使用靜態型別語言的話，能夠從編譯器那裡得到一些幫助，而那些擁抱動態型別語言的人會更傾向於依賴他們的單元測試
  65. 預防錯誤
    1. 應該尊重使用者的偏好來輸入資訊，而不是資料本身
    2. 為所有動作提供不同層次的撤消操作——尤其是那些可能會破壞和修改使用者資料的操作
    3. 用日誌記錄撤銷動作，並且加以分析，凸顯出介面的哪部分會誘導使用者犯下無意識的錯誤
  66. 專業程式設計師
    1. 在專業程式設計師身上唯一最重要的一點就是個人責任感。專業程式設計師對他們的職業、估算、承諾的日程、錯誤和技藝都敢於負起責任，從不會把責任推卸到別人身上
    2. 如果你是一名專家，你就要對自己的職業負責，對閱讀和學習負責。你負責跟上這個行業和技術的發展。很多程式設計師都認為這應該由僱主來給他們培訓。對不起，這錯得離譜
    3. 對於多數專案而言，問題跟蹤系統的存在就是粗心大意的徵兆。只有巨無霸型的系統才有bug列表，bug數量才會大到需要自動化管理
    4. 專家是可以信賴的。他們對自己的職業負責，對程式碼的正常工作負責，對他們技藝的質量負責。即便是最後期限迫近，他們也不會放棄原則。事實上，隨著壓力增大，專家會更加有條不紊，他們認為這是正確的
  67. 把一切都置於版本控制之下
    1. 許多專案都有一個活躍的開發分支，以及一個或多個為當前正在支援的已釋出版本所建立的維護分支
  68. 放下滑鼠，遠離鍵盤
  69. 閱讀程式碼
  70. 讀懂人性
    1. 相互理解的能力不是來自於共享的定義，而來自於共同的經驗和生活方式
  71. 經常重新發明輪子
    1. 如果對軟體開發中更深層次的東西一無所知，你就沒有足夠的能力創造出永恆之作
    2. 重新發明輪子對於一個開發人員的教育和技能培養來說很重要，就像健美運動員練舉重一樣
  72. 抗拒單件模式的誘惑
    1. 單件是值得抗拒的：
      1. 單一例項的需求通常都是想象出來的。在許多情況下，它都是純粹的投機，認為將來也不要更多的例項。在一個應用的設計裡傳播這種投機性，勢必導致在某些時候會很痛苦。因為好的設計會擁抱需求的變化，而單件不會
      2. 在概念上獨立的程式碼單元之間，會因單件引發潛在的依賴關係。該問題的存在既因為這種關係難於察覺，又因為它們在單元之間產生了不必要的耦合
      3. 單件承載了不明顯的持久狀態，這會妨礙到單元測試。
      4. 多執行緒會把更深的缺陷帶給單件模式。
    2. 單件的清理最後會變成挑戰：
      1. 對於明確的釋放單件可能沒有足夠的支援。例如，在一個外掛架構中，一個外掛只有所有物件清理乾淨之後再解除安裝才是安全的
      2. 沒有命令用於程式退出時隱含的清理單件。
    3. 必須把你對單件模式的使用限制在那些只要例項化一次的類裡面。不要從任何程式碼那裡來訪問單件的全域性訪問點
  73. 通向高效能之路佈滿了髒程式碼炸彈
    1. 在我們努力創造乾淨的程式碼過程中，軟體度量會成為一個威力強大的工具
  74. 簡單來自於刪減
    1. 挽回糟糕工作所耗費的時間會比預想的要多
    2. 處置壞程式碼的最好方法是徹底轉變程式設計思路，堅持無情的程式碼重構、移動或者刪除壞程式碼
    3. 程式碼應該是簡單的，它只有最小數量的變數、函式、宣告和其他一些語言必需的句法。額外的行、額外的變數……額外的一切，應該立即清除掉。那裡所有的，那裡保留下來的，應該剛好足夠完成任務、完成演算法或者執行計算，除此之外的任何東西都是多餘的。意外引入的不必要噪音只會使得流程晦澀難懂，使得重要內容隱匿無蹤
  75. 單一職責原則
    1. 單一職責原則：把所有會為同一個原因而更改的東西彙集在一起，把所有會為不同理由而更改的東西獨立開來——優秀設計的最根本原則之一
  76. 從Yes開始
    1. 從yes開始實際上就是作為一名技術領導的核心內容
    2. 通常，你會發現只要你知道提出要求時的背景，就會找到其他可以用來回應要求的方法
    3. 如果你能表述出一個令人信服的理由來說明為什麼這個功能要求跟現有產品格格不入，那麼你就有可能就你們是否正在構建一個正確的產品進行一次破有建設性的溝通。無論這次溝通的結論是什麼，每個人都會更加關注這個產品是什麼，以及不是什麼
    4. 從yes開始意味著你要和你的同事們並肩作戰，而不是相互對立
  77. 請轉回去做自動化、自動化、自動化
  78. 充分利用程式碼分析工具
    1. 不要讓測試成為質量保證的終點——充分利用現有的分析工具，也不要害怕推出你自己的工具
  79. 為必需行為測試，而不是偶發行為
    1. 測試的一個常見缺點就是與實現細節焊死在一起，而這些細節都是偶然的，跟所要求的功能關係不大
    2. 白盒測試用程式碼結構來決定什麼是測試用例所需要的
  80. 測試要嚴密而具體
    1. 構造軟體設計的方式有兩個：一個是讓它足夠簡單，沒有明顯的缺陷；另一個是讓它變得非常複雜，以至於看不出有什麼缺陷——Tony Hoare (快速排序的發明人，1980年獲得圖靈獎)
  81. 在睡覺的時候（或度週末的時候）進行測試
    1. 將橫跨不同部門和團隊的伺服器組成池，確保資源能夠充分利用
  82. 軟體開發的工程嚴密性來自測試
    1. 測試是通向軟體可再生產性和高質量的真正途徑，我們把回頭爭論是否要進行測試的行為視為極不專業的做法
  83. 關於狀態的思想
  84. 一人技短，二人技長
    1. 僅僅作為一名技術專家已經不夠了，你還必須高效的與其他人一起工作
  85. 錯上加錯就是貌似正確（並且難以糾正）
  86. 我寫程式碼為人人，人人為我寫程式碼
    1. 創造軟體是技術活動和社會活動的混合
    2. 我們和每個人一起分擔著提高成功可能性的責任
    3. 我們很少很少會寫只給自己用的程式碼
  87. Unix工具是你的好朋友
  88. 使用正確的演算法和資料結構
  89. 冗長的日誌會讓你睡不安枕
    1. 太多的日誌等於沒有日誌
  90. WET掩蓋了效能瓶頸
    1. DRY - Don't Repeat Yourself
    2. WET - Write Every Time
    3. DRY可以幫助我們找出並修復效能瓶頸，這在WET程式碼裡是很難發現的
  91. 當程式設計師和測試人員開始合作的時候
  92. 編寫程式碼時要像餘生都要給它提供支援一樣
    1. 你會發現多年前編寫的程式碼依然影響著你的職業生涯，不管你是否樂意這樣。
    2. 你的身後流下了一條鮮明的軌跡，其中蘊含你的知識、態度、主張、專業主義、誠意以及對於你設計編寫的每一個方法、類、模組的投入程度
  93. 使用例項編寫小函式
  94. 測試為人而寫
  95. 你應該關心你的程式碼
    1. 貧乏的技術基礎之上不會產生好的程式設計師
    2. 好的程式設計師依賴於採用專業途徑，即使有現實世界的束縛和軟體工廠的壓力，也一直想著寫出最好的軟體
    3. 與其他程式設計師一起和睦共事。沒有一個程式設計師是一座孤島。幾乎沒有程式設計師是單槍匹馬工作的；多數工作都是程式設計師抱團作戰的
    4. 你要希望團隊有可能寫出最好的軟體，而不是讓你自己顯得很聰明
  96. 心口不一的客戶
    1. 不要簡單的用客戶的言辭來重申他們告訴你想要的是什麼。在與客戶談話過程中，要換他們的言辭，然後從他們的反應裡判斷
    2. 在交談中使用視覺化目標有助於加大注意力的廣度，提高資訊的保持率

相關推薦

每個程式設計師應該瞭解的97件事情

原文：http://dearymz.blog.163.com/blog/static/205657420139243750104/ 正文之前 熟知軟體開發的人都知道這個行業裡充滿了一次次悲壯的失敗，每一座成功專案的豐碑下都埋葬著無數同類型的失敗專案。大多數軟體專案都像是

作為程式設計師應該瞭解的32個演算法（持續更新）

演算法就是解決問題的一種模式，通過演算法我們可以更輕鬆快速的解決問題。作為程式設計師，我們應該熟練掌握一些演算法並瞭解多個演算法。 我會持續不斷的更新這篇文章，爭取把這些演算法都給描述一下，用自己的思維方式給大家講解一下。 來自百度百科： 演算法（Algori

Java程式設計師應該瞭解的10個面向物件設計原則

摘要：Java程式設計最基本的原則就是要追求高內聚和低耦合的解決方案和程式碼模組設計。檢視Apache和Sun的開放原始碼能幫助你發現其他Java設計原則在這些程式碼中的實際運用。 面向物件設計原則是OOPS（Object-Oriented Programming Sys

優秀Java程式設計師應該瞭解的GC工作原理

一個優秀的Java程式設計師必須瞭解GC的工作原理、如何優化GC的效能、如何與GC進行有限的互動，因為有一些應用程式對效能要求較高，例如嵌入式系統、實時系統等，只有全面提升記憶體的管理效率 ，才能提高整個應用程式的效能。 一個優秀的Java程式設計師必須瞭解GC的工作原理、如何優化GC的效能、

每個程式設計師應該知道的最基本的東西是什麼？

這是我頭腦中快速理出來的一份清單…… 1.糟糕的架構比糟糕的程式碼導致更多的問題。 2.你會花更多的時間思考而不是編碼。 3.獲得更多工資的最好機會是在你受僱之前先談判薪水。 4.人際關係技能比技術技能更能決定你的成功。 5.使用者會發現令人印象深刻和奇怪的方法來解決他們自己的問題。 6.更頻繁地提交程式碼

程式設計師應該瞭解的數字

幾年前的一篇文章了，關於程式訪問儲存器所需時間的文章。對於程式訪問cache、記憶體、硬碟、網路等裝置，只是大概知道訪問哪些裝置快，哪些裝置慢；具體多塊或多慢，沒有明確概念。現代的裝置訪問速度已經超過幾年前，但是瞭解這些數值仍然有意義。 首先明確一下時間

Java程式設計師應該瞭解的10個面向物件…

     面向物件設計原則是OOPS（Object-Oriented Programming System，面向物件的程式設計系統）程式設計的核心，但大多數Java程式設計師追逐像Singleton、Decorator、Observer這樣的設計模式，而不重視面向物件的分析和設計。甚至還有經驗豐富的

Java程式設計師應該瞭解的10個面向物件的設計原則

面向物件設計原則是OOPS（Object-Oriented Programming System，面向物件的程式設計系統）程式設計的核心，但大多數Java程式設計師追逐像Singleton、Decorator、Observer這樣的設計模式，而不重視面向物件的分析和設計。

關於資料庫，程式設計師應該瞭解的那些事

資料庫的選型 對於很多程式設計師來說，公司選擇什麼樣的資料庫，基本不需要你來決定。當你加入一個公司的時候，公司的大部分技術選型已經確認，特別是資料庫選型，因為資料庫一旦選擇，後期遷移的代價還是很大的。 ​ 隨著大資料時代的來臨，湧現出了很多新型資料庫，在公司遇到資料效能瓶頸，喊去IOE口號或者是想嚐鮮時，

每個程式設計師都應該瞭解的記憶體知識（二）

http://web.itivy.com/article-347-1.html 接下來的章節會涉及更多的有關訪問DRAM儲存器的實際操作的細節。我們不會提到更多有關訪問SRAM的具體內容，它通常是直接定址。這裡是由於速度和有限的SRAM儲存器的尺寸。SRAM現在應用在

每個程式設計師都應該瞭解的 CPU 快取記憶體 英文原文：Memory part 2: CPU caches

現在的CPU比25年前要精密得多了。在那個年代，CPU的頻率與記憶體匯流排的頻率基本在同一層面上。記憶體的訪問速度僅比暫存器慢那麼一點點。但是，這一局面在上世紀90年代被打破了。CPU的頻率大大提升，但記憶體匯流排的頻率與記憶體晶片的效能卻沒有得到成比例的提升。並不是因為

程式設計師需要知道的97件事情之 ------- 謀定而後動

[size=medium] 本人英語抄過4級，奇爛無比，翻譯這個實屬蛋疼，錯誤是肯定有的，而且是翻不出出來就是隨便猜，歡迎指出，謝謝啦。但願我能夠翻完我看的懂的.... 原連結：oreilly的程式設計師需要知道的97件事http://programmer.97th

程式設計師需要知道的97件事情之 ------- 簡單就是美

本人英語抄過4級，奇爛無比，翻譯這個實屬蛋疼，錯誤是肯定有的，而且是翻不出來就只是隨便猜，歡迎指出，謝謝。但願我能夠翻完我看的懂的.... 原連結：oreilly的程式設計師需要知道的97件事http://programmer.97things.oreilly.com/

每個程式設計師都應該瞭解的記憶體知識1——記憶體概述

1、概述     早期的計算機很簡單，它的各種元件如CPU、記憶體、大容量儲存和網路介面都是一起開發的，所以效能差不多。舉個例子來說，記憶體和網路介面提供資料的速度不會比CPU快多少。     這種情況隨著計算機基本結構的固化和各子系統的優化慢慢地發生了改變。其中一些元件

《程式設計師應該知道的97件事》

 False consensus bias虛假同感偏差 柏拉圖：風格之美、和諧、優雅及優美的節奏，盡在於簡單 童子軍規則：盡力去做，讓你離開時的世界比你找到它時還要好一點 (Robert Stephenson Smyth Baden-Powell) 電腦科學的

讀《程式設計師應該知道的97件事》筆記

1技術債務和童子軍規則 技術債務當你發現必須在“幹得好”和“幹得快”之間做出抉擇的時候，一般都會選擇“幹得快”，並提醒自己將來再來返工。下一輪迭代自有其新的問題，工作重點轉移到新問題上，老問題還存在。Martin Fowler把它分成：蓄意和無意把技術 債務立即記錄到任務卡

每個程式設計師都應該瞭解的十一句話

1.技術只是解決問題的選擇，而不是解決問題的根本 我們可以因為掌握了最新的JavaScript框架ahem、Angular的IoC容器技術或者某些程式語言甚至作業系統而歡欣雀躍，但是這些東西並不是作為程式設計師的我們用來解決問題的根本——它們只是用於幫助我們解決問題的簡單工具。 我們必須非常謹慎，不要對某項正

每個程式設計師都應當瞭解的11句話

1.技術只是解決問題的選擇，而不是解決問題的根本 我們可以因為掌握了最新的JavaScript框架ahem、Angular的IoC容器技術或者某些程式語言甚至作業系統而歡欣雀躍，但是這些東西並不是作為程式設計師的我們用來解決問題的根本——它們只是用於幫助我們解決問題的簡單工具。 我們必須非常謹慎

一名3年工作經驗的程式設計師應該具備的技能（寫得很好，果斷轉） 因為和同事有約定再加上LZ自己也喜歡做完一件事之後進行總結，因此有了這篇文章。這篇文章大部分內容都是面向整個程式設計師群體的，當然因為LZ本身是做Java開發的，因此有一部分內容也是專門面向咱們Java程式設計師的。

因為和同事有約定再加上LZ自己也喜歡做完一件事之後進行總結，因此有了這篇文章。這篇文章大部分內容都是面向整個程式設計師群體的，當然因為LZ本身是做Java開發的，因此有一部分內容也是專門面向咱們Java程式設計師的。 簡單先說一下，LZ座標杭州，13屆本科畢業，算上年前在阿

[轉]國外程式設計師推薦：每個程式設計師都應該讀的非程式設計書

五年前有網友在 Stackoverflow 發帖提問：『程式設計師應該讀哪些非程式設計方面的書？』。有很多程式設計師響應，他們在推薦的同時也寫下了自己的評語。本文摘編其中 29 本書，下面就按照各書的推薦數排列。另外，本月初我們在伯樂頭條也發起了相同的討論帖《你最喜歡的非程式設計書是哪一本？》，已有很多的朋友