Pages

搜尋此網誌

2015年6月13日 星期六

TDD 分享三部曲 - 之一,測試:開發的源頭,自動化的起點

TDD 分享三部曲 - 測試:開發的源頭,自動化的起點

enter image description here

前言

近期(2015 年中)與社群大大一起去國內某資訊公司分享 Agile 開發流程,我負責說明 TDD。

之所以要講 TDD 也是因為我個人覺得這是很重要的觀念,特別是團隊開發的情形,更需要這樣的工法輔助。

因為很重要,加上這次分享已經講第三次 TDD 了 XD。

也因為是第三次,也算是一個里程碑,想說為自己記錄一下,也讓有需要的人可以參考 :)

題目

題目: 測試:開發的源頭,自動化的起點
地點: Mozilla Space
主辦: Node.js Party
日期: 2014/11/13
活動頁: KKTIX
簡報: https://www.slidenow.com/slide/98

這是第一次在公開場合說明 TDD,是有一陣子的簡報,除了簡報分享,想要把簡報過程,收到的回饋記錄一下。

這份簡報是用 slidenow 進行,是一個用 markdown 來寫簡報的好工具,使用上很方便,也是國內某大大的作品。

這次準備的簡報,想法是透過簡單的介紹,讓大家了解 TDD 怎麼進行。

簡報過程就不多做說明,大家可以看連結,將針對遇到的問題,還有個人的一些感想與大家分享。

與會者中,提到的問題有以下,因為太久,只能說是印象中…

遇到的問題

test 佔開發中的多少比例?

老實說,我不知道,但正確的觀念是 test 本來就是開發的一部分,而不是分開的兩件事。

唯有把它當作必要的事,才有可能執行。

先面對問題,才能解決問題。

test 會拖慢開發速度嘛?

其實並不會,反而會加快開發速度,因為 test 都在 command line 執行,確認結果,不需要啟動 browser 進行,因此可以更專注於程式的開發,開發過程也會較有節奏。

新進人員怎麼適應?

有請 team member 分享,開發後端 api 實作時,不准開 browser 確認結果,都在 command line 進行,強迫沈浸在 test 的環境將任務完成。

經過跳離舒適圈的過程,也讓原本沒有 test 觀念的 member 能夠理解 test 的好處。

主管不推,同事不配合怎麼辦?

需要 fight,或許可以先自我進行,試著做出成效,展現好處後,讓其他人也看到它的好處,漸漸的就會有更多人加入。

結論

因為這次題目的關係,與會者都是對 test 有興趣的人,所以會議進行中專注度還蠻集中的,可以看得出來認真的程度,會後的討論也很踴躍,表示很想了解 TDD 的一些細節。

不過就我的感想是,大家都有痛,但好像都礙於現況,沒辦法推進,或是情勢比人強,專案進度趕或是已經 out of control。

其實,若真的有痛,就是一點一點改善,慢慢的導回正軌。

那時候柯 P 有一句話很讓我印象深刻:

先面對問題,才能解決問題。

加上最近很喜歡一句話:

念念不忘,必有迴響

最後近期讀到很推薦的「 被討厭的勇氣」這本書

其實,解決問題不就是這樣:

  1. 知道並且感受到問題(有痛):先面對問題,才能解決問題。
  2. 念念不忘(有恨):不停的找可能的做法,找到可行解
  3. 不怕被討厭的行動(決心改善):因為是對的事,堅持行動,即使會被討厭、或組織不支持還是要進行。

如果每個人遇到問題,都能夠正視,並且積極面對,從個人開始,我想世界會越來越好的。

或許每個人的做法不一樣,一點心得與大家分享。

張貼留言