最近在熊節老師的帶領下，很多小伙伴們進入了TDD和重構練功房，為什么來練功房，因為基本功太差，有幸作為基本功最差的學員（沒有之一），在經過幾天的練習，逐漸感受到自己的基本功真的很差。好在也逐漸領悟一些提高效率的訣竅，因此想趕緊做一下總結，希望可以給予新手一些幫助，如果有哪里寫得不合理的地方，歡迎指正。

承認能力不足

承認自己代碼寫得爛，基本功不行。 這很難，沒關系，這可能是事實，接受他，慢慢會有意外收獲的，而且還會很感謝那些“懟”自己和提供建議的大神，因為對我來說，什么是“好”的定義正在發生變化。

專注

想要提高效率的第一件事就是專注，如何才能專注呢？重視它，重視一件事，就會發現腦海里只有它，在還沒有完成之前，這件事目前的優先級最高。

使用快捷鍵

在 TDD 時強迫自己使用快捷鍵，盡量減少使用鼠標和觸摸板。如果還想把使用 IDE 的效率調到極致，還需要發掘新的快捷鍵。分享最近新學到的和新設置的快捷鍵(Intellij IDEA)：

• 窗口控制
  • 打開/關閉 左側項目視圖 => Command + 1
  • 打開/關閉 底部Debug視圖 => Command + 5
  • 查看文件結構 => Command + 7
  • 打開/關閉 Terminal => Option + T
  • 關閉所有 Tool Window => Control + Option + C
• 分屏
  • 垂直分屏 => Option + 1
  • 水平分屏 => Option + 2
  • 分屏切換 => Option + Tab
  • 文件切換 => Shift + Command + [/]
• 測試
  • Run/Debug 立即測試 => Control + R / Control + D
  • Run/Debug 選擇測試 => Control + Option + R / Control + Option + D
  • Step Over => Option + N
  • Resume Program => Option + Command + R
  • Evaluate Expression => Contrl + Command + E
  • 生成單元測試模板 => Command + N
• 自動生成代碼或文件 => Option + Enter 、Command + N

能生成，別手寫

如果使用快捷鍵可以使編碼效率更快，那么善用 IDE 的代碼生成功能能助編碼效率上一個臺階。TDD 有相當一部分代碼是不需要手寫的，只需要聲明需要什么，然后交給 IDE 自動生成，例如（我從群里面拿的兩張圖）：

這種方式可以先明確做什么、需要什么和得到什么，避免一開始就陷入實現細節。熟練掌握這種思維，大部分的類、函數、輸入和返回值類型等代碼片段都可以自動生成。

讀懂題目

最浪費時間的不是花了 4 個小時做對了事情，而是花了 4 個小時得到了不符合需求的程序。 為了保證正確地做事，需要先做正確的事， 在面對這種問題，最近經常使用的方式是先簡化問題，然后尋找重要概念，并且繪制成一張簡單的術語表，而且這個過程我還會把案例中描述的內容在腦海里演練一遍，然后不斷問自己還未理解的問題：

例如 BowlingGame 這個案例，我會在腦海中虛擬出合適的場景，想象自己就是投保齡球那個人，包括在做什么、看到了哪些東西、可以投幾輪、每輪投幾次、有哪些計分規則；還會問自己一些問題，例如是投 1 次就計 1 次分，還是投完所有輪數再計分？哪種方式比較聰明、比較簡單？...

然后在案例中尋找一些重要概念并記下來，這一步需要不斷改進，隨著對問題的理解越來越深入，就會發現更多隱喻的概念，下面是初步得到的概念：

概念描述

BowlingGame	保齡球游戲
roll	投球
score	分數

把事情記下來

大腦不擅長同時處理多件事，也不擅長記住很多事情，如果發現事情不能很快完成，那么一個比較好的方式是把事情記起來，給大腦減減壓，然后一個一個消滅。 例如有些題第一次做并不簡單，采用 TDD 做完經常需要幾個小時，難一些的題我還斷斷續續做了超過一天的時間，邏輯復雜一點的題經常記不住（github.com/lynings/tdd… ），然后又得去閱讀題目，再分析，超級浪費時間。這種情況可以考慮先 tasking，拆分成小問題后一件件記下來，然后邊做邊調整，例如：

尋找新思路

一條路走得通，只是太難走了，那換條路試試。 之前在 code kata 時做了一遍 Args 案例，這個案例我花了很多時間在解析參數，而代碼簡直可以被當做反面教材，熊節老師直呼寫得太丑，干了太多事。

在摸索一段時間后換了另一種思路，效率就快了很多，經過了 7 次練習，最終那道題我用了 27 分鐘做完，還寫了 22 個單元測試。

又例如前幾天在做 Anagrams 案例的時候，分類算法花了很多時間，代碼寫得亂七八糟不說，運行效率也非常低下，運行了幾分鐘還沒完成分類，只能強制關閉程序

最后換了個思路，33w+ 的單詞分類只需要3秒就搞定，效率高了xxx倍，重點是代碼簡化了非常多。

這些事情我還可以列出很多，最后我把這種“費力不討好”的事情總結為思路不對，對于新手來說，好的思路可能需要幾個小時甚至幾天才能想到，可能還需要找相關資料閱讀，或者練多幾遍后復盤分析，不過這是值得的，看著代碼越來越簡潔，編碼效率越來越高，心里還是樂的。

小步迭代

步伐小，思路才會清晰。 有沒有遇到過瘋狂輸出 5 分鐘以上，一個測試還沒能通過；有沒有遇到寫著寫著前面的大部分測試都失敗，然后又花了很長時間才使測試通過；有沒有遇到無論怎么練，效率還是沒有提高，這很可能是一下子步伐邁太大了。

例如我在練 Args 這個案例的時候，每次我都是先測試驅動出 ArgsParser 類 ，前 4 次至少都要一個鐘以上，第 5 和第 6 次縮減到 45 分鐘，因為我更專注，并且熟練了快捷鍵和自動生成代碼的技巧，但是直接面對的問題較大，而且有越做思路越復雜的感覺，還經常影響到之前通過的測試。在復盤分析的時候，發現大部分時間是花在了思考應該怎么寫邏輯上，然后我就調整了策略，先用測試驅動出 Schema 和 Args 類，因為這兩個類互相獨立，非常快就做好，最后再測試驅動出 ArgsParser，因為它依賴前面兩個類，這樣每一步都變得很順暢，因為考慮的問題少了，思路也清晰了。

瓶頸分析

一道題練一遍數據樣本太少，不利于分析，試著給自己定一個小目標，例如遵循 TDD，在保證質量的前提下，練到破自己或某位大神的最好記錄。 我認為瓶頸可以用時間去衡量，例如同樣的問題，別人做了多久，最好成績是多少，自己跟他的差距是多少，對別人來說那叫效率，對自己來說，那叫瓶頸，這通常需要把同一道題練多幾遍，然后做復盤分析，找找自己卡在哪里的時間最長，在反饋中持續改善。

例如我學 TDD 經歷了以下瓶頸：

缺乏 TDD 的理論知識，自己問自己什么是 TDD 都回答不了，因此我把 Kent Beck 的《Test Driven Development》研讀了好幾遍，并且在 “TDD 討論群” 和 “敏捷中國史” 這兩個群中問了很多關于 TDD 的問題，很多大神給了我很多建議，真的非常感謝，并且自己還寫了TDD 原理總結；

紅/綠/重構的理解和習慣的養成，因此我做了一些案例，寫了幾篇 TDD 實踐案例文章，但是實踐效果很不好。

程序設計能力和任務拆分能力的不足，因此我讓張逸老師幫我推薦了一些可以提高設計能力的書給我，例如《敏捷軟件開發》、《代碼簡潔之道》、《修改代碼的藝術》、《實現模式》、《重構》等等，于是我就踏上了啃書之旅，雖然沒能得到大師人物的真傳，不過此時的我已經對簡潔代碼有了更多的理解；

基本功太差，機緣巧合熊節老師建了一個群 “TDD和重構練功房”，專門給一些 TDD 的愛好者練習和討論，俗話說練武不練功，到頭來一場空，在這里每天都有人在練習，有代碼，有討論，有建議，有反饋。自己在實踐的過程中遇到了很多問題，例如如何減少理解題目所用的時間？任務應該如何分解？TDD 效率為什么沒有提高？測試應該怎么寫？從哪里測試驅動等等，這些問題在這里也慢慢有了一些感悟。

尋求反饋

阻礙我們寫出好代碼的，首先是根本不知道代碼能寫多好。 所以才需要讀書（只讀好書），需要練習，同時也需要反饋。把 TDD 實踐的成果展示出來：哪個案例，用了多長時間，代碼在哪里，看看讀者能不能看懂，同時積極響應反饋，持續改善。

幫助他人

懟我的人和給我建議的人我會感謝，比我經驗少的人，我也會去幫助他。 因為幫助他人會讓自己思考更多自己沒有遇見的問題。

刻意練習

一個小提琴家在去表演的路上迷路了，他在街角攔住了一位長者，問道：“怎么才能去卡耐基音樂廳（Carnegie Hall）”。長者看了看小提琴家，又看了他手中的琴，說道：“你還得練，孩子，還得練！”。

這是一個笑話，不過大部分真實情況就是那樣子，你的基本功怎么樣呢，來練一個試試，往“死”里練那種。

---

歡迎關注我的微信訂閱號，我將會持續輸出更多技術文章，希望我們可以互相學習。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的提高 TDD 效率的一些小诀窍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。