學習 TDD 必看的聖經本,當然就是 Kent Beck 的 TDD by Example。在取得 Kent Beck 授權之後,將書中每一步程式碼的演進,都放到 GitHub 的 commit history 上分享給各位讀者參考,讓大家既能專注在每一步的變化,又能兼顧全局,還可以在任何一步的 sample code 繼續往下練習。
生產力 = 你的設計功力(能力) + 最佳化開發環境與設定(神兵) + 對的開發方式(招式)
【極速開發】就是用來解決實務上大家總說「時間不夠」的問題,因為時間不夠,所以我沒法子寫單元測試,沒法子重構,沒法子 TDD,沒法子 code review,沒法子把事情作到最好。
我認同「時間不夠」是個問題,然而卻很少人去改善或解決這個問題。各位將會從此學到,如何建立自我刻意練習的模型,將所有工具的整合起來發揮最大綜效,透過正確的開發方式與順序,讓你寫代碼時能行雲流水,並且兼顧設計、品質與生產力。
活動以 Coding Dojo 方式進行,挑選合適的 Kata 當需求,帶著大家分組進行需求的釐清、測試案例探索、實例化需求、設計與分析。
【6/5 更新】7/3(六)活動取消 很遺憾通知各位,熱血 Coding Dojo – 202102 台中(延 […]
在 Mac OS 上使用 IDE 無法用 Opt + shortkey 來選擇想要點選的功能嗎?只要加一行設定就可以讓你正常使用 mnemonic 的便利性囉。不用再為了這件事,而得讓雙手離開鍵盤,只為了用滑鼠點那個被該死的智慧輔助鍵盤擋住的功能。
公司對新人到職三個月是怎麼安排的呢?給一堆投影片叫他自己看,然後報告?給他知識管理系統連結,要他自己去看?還是上幾次課,然後考試呢?給他無關緊要的ticket讓他修嗎?如果你希望新人用最短時間融入團隊真實工作,請試試看透過 pair programming,效果顯著。
從陪小孩寫功課的過程,了解 code review 與 pair programming 的差異。code review 是個落後指標,發現問題的時間點越晚,修復成本就越高。而當 code review 淪為線上稽核的形式,往往在往返之間的誤解、等待就會造成極大的浪費。
讓大家依據實務需求完成代碼、加入單元測試、code review 、code smells 辨識,且依照成員的 legacy code 現場示範重構並指導練習重構、測試案例探索/分群/排序、邏輯樹拆分、TDD 循環與 baby step、迭代堆砌產品代碼增量。
單元測試是開發軟體產品過程中,與品質、設計相關最重要的基本工程實踐,如果不會單元測試,很多重構無從下手。如果不會單元測試,無法駕馭測試驅動開發。
生產力 = 你的設計功力(能力) + 最佳化開發環境與設定(神兵) + 對的開發方式(招式)
【極速開發】就是用來解決實務上大家總說「時間不夠」的問題,因為時間不夠,所以我沒法子寫單元測試,沒法子重構,沒法子 TDD,沒法子 code review,沒法子把事情作到最好。
我認同「時間不夠」是個問題,然而卻很少人去改善或解決這個問題。各位將會從此學到,如何建立自我刻意練習的模型,將所有工具的整合起來發揮最大綜效,透過正確的開發方式與順序,讓你寫代碼時能行雲流水,並且兼顧設計、品質與生產力。