如何讓你實踐TDD能成功的方法


Making TDD Stick: Problems and Solutions for Adopters
http://www.infoq.com/articles/levison-TDD-adoption-strategy

Jan 05, 2009
Posted by Mark Levison
Publsihed in InfoQ


作者調查了一些人, 問他們之所以無法採用TDD的原因為何, 收集到了以下原因
1. People find it hard to TDD on their own, when they don't have much experience with it.
2. TDD Education so far has focused too much on problems that are simpler than the real world.
3. More time is needed to experiment and try without the usual pressure of releasing software at a specific date.
4. Languages used in the real world, like Visual Basic and JavaScript, are never used as examples in unit test documentation or classroom exercises.
5. The average code base is full of legacy code and no training was provided in how to improve this code.
6. There is never enough time to learn – there is always (artificial) pressure to ship product soon, and so we can't take the time to improve.

然而這些都是所看到的表象, 那真正前在下面的問題是什麼呢?

答案可能是TDD真的是非常困難去學習, 學習時間可能要持續2到4個月, 並且在這中間生產力會下降. 雖然最後結果是明顯的, 但問題是要多久才能到這樣的境界? 許多工程師可能幾天之後就放棄了

目前有許多方法可以幫忙解決這些問題, 但是還是不夠. 作者列出這些方法的問題
1. Classroom training
- the examples are too easy and don't relate to real problems
- no enough chance to practice.

2. Online training
- there still isn't enough chance to practice.
- without interaction with other students.

3. One-on-one mentoring
- doesn't scale beyond a few members of one team

4. Books
- few developers like to read books about their trade craft
- like the online courses, the problem is learning on one's own.

此外大量的legacy codes讓這個問題變的更棘手. 工程師可能會問到一個問題: "How do I test these tightly coupled objects? This code is complicated, how do I test this algorithm?"

那所以到底要怎樣才會work呢? 根據前面的問題, 我們可以看出主要是受困於: a lack of depth and no collaboration

所以一個完整的策略, 不只要包含不同的學習方法, 並且還要考量許多因素. 以下是作者認為要考慮到的因素

1. Classroom Training
- 對大部分的人來說還是最有用的
- 但是這只是幫助了解TDD是什麼, 而不是讓人們會採用它
 
2. Online Training
- 有助於建立基本的認識, 或是概念
 
3. Patience
- 套用一個新的practice通常會超過你所能想像的久, 所以要有耐心
 
4. Measure
- 使用 code coverage tools (e.g. Emma, Cobetura, NCover, ...)來告訴你做的多或是做的少
- 但是這並不一定代表做多你的quality就一定是好的
 
5. Instill Pride
- 工程師需要知道好的程式和測試是看起來像怎麼樣的, 並且也需要知道他們是值得花這些精力去做到這些事情的
- Bob Martin有寫一本書叫"Clean Code", 有提到這些事情, 值得參考一下
 
6. Management
- 高層要支持是不變的道理
- 需要諒解這是需要時間並且依開始是會變慢的

7. Pair Programming
- 如果你遭遇問題, 不知道如何處理, 有人可以一起討論將會有很大的幫助
- 即使和初學者一起合作也會有意想不到的收穫
 
8. Community
- create a community with your organization (or city) to share experiences.
- learn from each others' successes and mistakes.
- a place to help grow the culture necessary for TDD.
- an opportunity to share new ideas.
 
9. Coding Dojo
- A place to practice solving a small problem together.
- Its a safe, collaborative environment with an emphasis on exploring a problem as a group and not necessarily solving it.
 
10. 讀書會
 
11. 週期性拜訪 Coach
- can help a team get back on track when they have fallen of the sled and stopped practicing TDD.
- In theses case just pairing with one or two people can help re-infect the entire team.


根據這些因素, 作者認為這個策略的核心價值是: creating conversations and increasing collaboration around TDD. 並且著重於這些領域: Pair Programming, Coding Dojo and a Reading Workshop.

1. Coding Dojo (修練程式的道場)
- a small group of people (max 15),
- solve a problem using TDD (adapted from Danilo Sato):
- choose very small problems to start
- process
 The work is done on one computer with the output projected for all to see
 Coding is done in pairs
 One member of the pair switches out every 5-10 minutes (7 worked well for us).
 The coders should explain what they're doing, so the audience understand what is happening at the keyboard.
 The audience should only comment on the design when the tests run cleanly. When tests are failing they should ask questions.
 If the audience is confused the work should stop and the coders should explain what's going on.

2. Reading Workshop
- 作者推薦了一些好書, 來幫助大家快點上手
 on a Java Project: Lasse Koskela's Test Driven: TDD and Acceptance TDD for Java Developers;
 on a .NET Project: Kent Beck's Test Driven Development: By Example;
 as you learn more Gerard Meszaros xUnit Test Patterns: Refactoring Test Code
 if your code wasn't developed with TDD: Michael Feathers Working Effectively with Legacy Code.
- Typically teams try to cover one to two chapters a session. The pace is slow enough that people can read outside of work without it becoming a burden. In
addition, it allows enough time for in-depth discussion of a few items in the chapter.

最後, 作者還提出要成功的一些關鍵要素
- Patience, Practice, Depth
- Management Support
- Multi-pronged approach
- Developers helping developers

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()