提高 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 經歷了以下瓶頸:
尋求反饋
阻礙我們寫出好代碼的,首先是根本不知道代碼能寫多好。 所以才需要讀書(只讀好書),需要練習,同時也需要反饋。把 TDD 實踐的成果展示出來:哪個案例,用了多長時間,代碼在哪里,看看讀者能不能看懂,同時積極響應反饋,持續改善。
幫助他人
懟我的人和給我建議的人我會感謝,比我經驗少的人,我也會去幫助他。 因為幫助他人會讓自己思考更多自己沒有遇見的問題。
刻意練習
一個小提琴家在去表演的路上迷路了,他在街角攔住了一位長者,問道:“怎么才能去卡耐基音樂廳(Carnegie Hall)”。長者看了看小提琴家,又看了他手中的琴,說道:“你還得練,孩子,還得練!”。
這是一個笑話,不過大部分真實情況就是那樣子,你的基本功怎么樣呢,來練一個試試,往“死”里練那種。
歡迎關注我的微信訂閱號,我將會持續輸出更多技術文章,希望我們可以互相學習。
《新程序員》:云原生和全面數字化實踐50位技術專家共同創作,文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的提高 TDD 效率的一些小诀窍的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: MaxCompute 图计算开发指南
- 下一篇: 人工智能取代医生AI画出鼻咽癌放疗靶区,