提升 TDD 效率的一些小訣竅

最近在熊節老師的帶領下,不少小夥伴們進入了TDD和重構練功房,爲何來練功房,由於基本功太差,有幸做爲基本功最差的學員(沒有之一),在通過幾天的練習,逐漸感覺到本身的基本功真的不好。好在也逐漸領悟一些提升效率的訣竅,所以想趕忙作一下總結,但願能夠給予新手一些幫助,若是有哪裏寫得不合理的地方,歡迎指正。git

認可能力不足

認可本身代碼寫得爛,基本功不行。 這很難,不要緊,這多是事實,接受他,慢慢會有意外收穫的,並且還會很感謝那些「懟」本身和提供建議的大神,由於對我來講,什麼是「好」的定義正在發生變化。github

專一

想要提升效率的第一件事就是專一,如何才能專一呢?重視它,重視一件事,就會發現腦海裏只有它,在尚未完成以前,這件事目前的優先級最高算法

使用快捷鍵

在 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 自動生成,例如(我從羣裏面拿的兩張圖):ide

這種方式能夠先明確作什麼、須要什麼和獲得什麼,避免一開始就陷入實現細節。熟練掌握這種思惟,大部分的類、函數、輸入和返回值類型等代碼片斷均可以自動生成。函數

讀懂題目

最浪費時間的不是花了 4 個小時作對了事情,而是花了 4 個小時獲得了不符合需求的程序。 爲了保證正確地作事,須要先作正確的事, 在面對這種問題,最近常用的方式是先簡化問題,而後尋找重要概念,而且繪製成一張簡單的術語表,並且這個過程我還會把案例中描述的內容在腦海裏演練一遍,而後不斷問本身還未理解的問題:單元測試

例如 BowlingGame 這個案例,我會在腦海中虛擬出合適的場景,想象本身就是投保齡球那我的,包括在作什麼、看到了哪些東西、能夠投幾輪、每輪投幾回、有哪些計分規則;還會問本身一些問題,例如是投 1 次就計 1 次分,仍是投完全部輪數再計分?哪一種方式比較聰明、比較簡單?...學習

而後在案例中尋找一些重要概念並記下來,這一步須要不斷改進,隨着對問題的理解愈來愈深刻,就會發現更多隱喻的概念,下面是初步獲得的概念:測試

概念 描述
BowlingGame 保齡球遊戲
roll 投球
score 分數

把事情記下來

大腦不擅長同時處理多件事,也不擅長記住不少事情,若是發現事情不能很快完成,那麼一個比較好的方式是把事情記起來,給大腦減減壓,而後一個一個消滅。 例若有些題第一次作並不簡單,採用 TDD 作完常常須要幾個小時,難一些的題我還斷斷續續作了超過一天的時間,邏輯複雜一點的題常常記不住(github.com/lynings/tdd… ),而後又得去閱讀題目,再分析,超級浪費時間。這種狀況能夠考慮先 tasking,拆分紅小問題後一件件記下來,而後邊作邊調整,例如:ui

尋找新思路

一條路走得通,只是太難走了,那換條路試試。 以前在 code kata 時作了一遍 Args 案例,這個案例我花了不少時間在解析參數,而代碼簡直能夠被當作反面教材,熊節老師直呼寫得太醜,幹了太多事。

在摸索一段時間後換了另外一種思路,效率就快了不少,通過了 7 次練習,最終那道題我用了 27 分鐘作完,還寫了 22 個單元測試。

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

最後換了個思路,33w+ 的單詞分類只須要3秒就搞定,效率高了xxx倍,重點是代碼簡化了很是多。

這些事情我還能夠列出不少,最後我把這種「費力不討好」的事情總結爲思路不對,對於新手來講,好的思路可能須要幾個小時甚至幾天才能想到,可能還須要找相關資料閱讀,或者練多幾遍後覆盤分析,不過這是值得的,看着代碼愈來愈簡潔,編碼效率愈來愈高,內心仍是樂的。

小步迭代

步伐小,思路纔會清晰。 有沒有遇到過瘋狂輸出 5 分鐘以上,一個測試還沒能經過;有沒有遇到寫着寫着前面的大部分測試都失敗,而後又花了很長時間才使測試經過;有沒有遇到不管怎麼練,效率仍是沒有提升,這極可能是一會兒步伐邁太大了。

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

瓶頸分析

一道題練一遍數據樣本太少,不利於分析,試着給本身定一個小目標,例如遵循 TDD,在保證質量的前提下,練到破本身或某位大神的最好記錄。 我認爲瓶頸能夠用時間去衡量,例如一樣的問題,別人作了多久,最好成績是多少,本身跟他的差距是多少,對別人來講那叫效率,對本身來講,那叫瓶頸,這一般須要把同一道題練多幾遍,而後作覆盤分析,找找本身卡在哪裏的時間最長,在反饋中持續改善。

例如我學 TDD 經歷瞭如下瓶頸:

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

尋求反饋

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

幫助他人

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

刻意練習

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

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


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

相關文章
相關標籤/搜索