高效能程序員的修煉

錯誤調試方法

1. 分析項目的整個運行流程，梳理各個環節，找到可能出錯的地方加以修改
2. 根據錯誤提示找到錯誤根源， 刪一段再執行一段
3. 小黃鴨調試法：強迫本身把遇到的問題說出來，詳細說出每一行代碼的做用以及實現的功能，必定要說出來，對人對物均可以。

高效能程序員的修煉

• 鍛鍊寫做能力
• 繞開絆腳石，直達目的地（重要）
• 專一於一項工做
• 學會閱讀源代碼
• 避免寫沒必要要的註釋：規範化類名與方法名
• 沒必要從頭開始複習，專一於當下
• 不要寫死代碼

卓越程序員密碼

• 早起先測試

• 別在臥室裏工做：

  • 別讓每週40小時的工做變成168小時的工做+睡覺+吃喝玩樂

• 寫代碼是不得已而爲之：

  • 思考爲何要寫它，有沒有更好的解決辦法

• 對休閒項目堅定說不

  • 開啓項目前問本身幾個問題：
  1. 每週花幾天，天天花幾個小時在這個項目上（可持續的工做量，堅持）
  2. 何時能把一個基本成型的產品展現給別人（可供測試的軟件）
  3. 哪一天向公衆發佈（夠用的軟件）
  4. 哪一天發佈第一個主要的更新版本
  • 設置一個最後期限，哪怕是隨意設的

• 仿造軟件：

  • 找一個你喜歡的網站或遊戲，把它仿造出來。在你真正的想作一件項目前，先作完這個。這個能促使你學到前沿的編程技術，並且能讓你更容易的被招聘公司選中。作3-5個這樣的仿製項目後，你就能實現任意的你想要的東西了。

• 每一個項目都要學到新東西：

  • 每次項目都努力使用一些聽到過但從未使用過的新東西。沒有使用過jquery，那下次項目中就使用它
  • 沒有試過測試驅動開發，下次項目就是你的實驗品

• 天天改進產品的兩個方面，即使是很是小的改進

CleanCode

童子軍軍規：離開時要比來時更整潔。

若是每段代碼都讓你感到深合己意，那就是整潔代碼。

整潔的代碼只作好一件事

一以貫之的命名法。統一命名方式

類名名詞、方法名動詞

整潔代碼是重構出來的，而非一開始就寫出來的，沒人能作到這種事情。

別給糟糕的代碼加註釋---從新寫吧。可是因爲咱們並不是英語國家，仍是須要多寫註釋的，不過是代碼的英文翻譯。

TDD（Test-Driven Development）：測試驅動開發，就比如數據抽取的公式，一開始不知道如何下手，換個角度想一想看怎麼測試，先設計個簡單的界面，思考須要傳遞什麼參數，一步步測試，一步步開發。測試能幫咱們想到開始開發時想不到的點，幫咱們確認需求。

測試代碼的簡潔度反映了業務代碼

TDD三大定律：

1. You must write a failing unit test before you write production code.（在編寫不能經過的單元測試前，不可編寫生產代碼）
2. You must stop writing that unit test as soon as it fails; and not compiling is failing.（只可編寫恰好沒法經過的單元測試，不能編譯也算不經過）
3. You must stop writing production code as soon as the currently failing test passes.（只可編寫恰好足以經過當前失敗測試的生產代碼。）

使用但儘可能少使用斷言語句。（保持測試的可重用性，每一個測試只測試一個功能，比如每一個方法只作一件事）

整潔的測試規則：FIRST

• Fast，快速，才能頻繁進行測試
• Independent，獨立，多個測試之間應該相互獨立，不能有任何關係
• Repeatable，可重複，測試應可在任何環境下經過
• Self-Validating，自足驗證，測試應該有布爾值輸出（或斷言），不管經過或者失敗都不該該查詢控制檯或者日誌確認測試是否經過。
• Timely，及時，測試應該及時編寫，剛好在使其經過的生產代碼以前編寫

單一權責原則：（Single Responsibility Principle）

• 類或模塊應該有且只有一條加以修改的理由

系統應該由許多短小的類而不是少許巨大的類組成。每一個小類封裝一個權責，只有一個修改的緣由，並與少數其餘類一塊兒協同工做達成指望的系統行爲。

重構通常都須要大動代碼，爲了保證程序的可正常運行，最好編寫一套測試用例，保證重構先後系統的正確性，在一步一步的重構時執行測試用例。