提升 TDD 效率的一些小訣竅

最近在熊節老師的帶領下，不少小夥伴們進入了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 經歷瞭如下瓶頸：

1. 缺少 TDD 的理論知識，本身問本身什麼是 TDD 都回答不了，所以我把 Kent Beck 的《Test Driven Development》研讀了好幾遍，而且在 「TDD 討論羣」 和 「敏捷中國史」 這兩個羣中問了不少關於 TDD 的問題，不少大神給了我不少建議，真的很是感謝，而且本身還寫了TDD 原理總結；
2. 紅/綠/重構的理解和習慣的養成，所以我作了一些案例，寫了幾篇 TDD 實踐案例文章，可是實踐效果很很差。
3. 程序設計能力和任務拆分能力的不足，所以我讓張逸老師幫我推薦了一些能夠提升設計能力的書給我，例如《敏捷軟件開發》、《代碼簡潔之道》、《修改代碼的藝術》、《實現模式》、《重構》等等，因而我就踏上了啃書之旅，雖然沒能獲得大師人物的真傳，不過此時的我已經對簡潔代碼有了更多的理解；
4. 基本功太差，機緣巧合熊節老師建了一個羣 「TDD和重構練功房」，專門給一些 TDD 的愛好者練習和討論，俗話說練武不練功，到頭來一場空，在這裏天天都有人在練習，有代碼，有討論，有建議，有反饋。本身在實踐的過程當中遇到了不少問題，例如如何減小理解題目所用的時間？任務應該如何分解？TDD 效率爲何沒有提升？測試應該怎麼寫？從哪裏測試驅動等等，這些問題在這裏也慢慢有了一些感悟。

尋求反饋

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

幫助他人

懟個人人和給我建議的人我會感謝，比我經驗少的人，我也會去幫助他。 由於幫助他人會讓本身思考更多本身沒有碰見的問題。

刻意練習

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

這是一個笑話，不過大部分真實狀況就是那樣子，你的基本功怎麼樣呢，來練一個試試，往「死」裏練那種。

---

歡迎關注個人微信訂閱號，我將會持續輸出更多技術文章，但願咱們能夠互相學習。