TDD 규칙은 간단하지만, TDD 를 배우는 것은 어렵고, 실천하기는 더 어렵다.
왜 그럴까? TDD 는 설계 방법이기 때문이다. TDD 의 규칙 리듬을 알고 따르려고 해도, 설계 용어들을 모르면 TDD 를 제대로 할 수 없다.
TDD 를 잘 하려면, 설계용어의 의미를 이해하고, 언제 적용하는지도 알아야 한다.
3. 우리가 하는 일은?
Implementation is the act of Coding?
Implementation is not the act of Coding?
http://c2.com/cgi/wiki?WhatIsSoftwareDesign
4. What is Software Design?
The final goal of any engineering activity is to create some kind of
documentation. When a design effort is complete, the design documentation
is given to the manufacturing team. This is a different set of people with a
different set of skills from those of the design team. If the design documents
truly represent a complete design, the manufacturing team can proceed
to build the product. In fact, they can proceed to build much of the product
without further assistance from the designers.
( Jack W. Reeves, The C++ Journal Vol.2, No.2, 1992 )
6. What is Software Design?
After reviewing the software development life cycle today, it appears that the
only software documentation that actually seems to satisfy the criteria of
an engineering design are the source code listings.
( Jack W. Reeves, The C++ Journal Vol.2, No.2, 1992 )
7. 우리가 하는 일은?
When you are programming, you are doing detailed
design. The manufacturing team for software is your
compiler or interpreter.
The source code is the only complete specification of
what the software will do.
http://c2.com/cgi/wiki?WhatIsSoftwareDesign
8. Source Code is Design Documentation
1. Software runs on computers. It is a sequence of ones and zeros. Software is not a program
listing.
2. A program listing is a document that represents a software design. Compilers, linkers, and
interpreters actually build (manufacture) software.
3. Software is very cheap to build. You just press a button.
4. Software is expensive to design because it is complicated and all phases of the
development cycle are part of the design process.
5. Programming is a design activity; a good software design process recognizes this and does
not hesitate to code when coding makes sense.
6. Coding actually makes sense more often than believed. Often the process of rendering the
design in code will reveal oversights and the need for more design effort. The earlier this
happens, the better.
7. Testing and debugging are design activities - they are the equivalents of design validation
and refinement in other engineering disciplines. They can not be short changed.
8. Formal validation methods are not of much use because it is cheaper to build software
and test it than to prove it.
( Michael Feathers )
10. Coding vs Design
우리가 코딩을 하고 있다고 생각한다면,
우리는 코딩을 하기 위해 생각할 것이고,
코딩을 위한 지식과 스킬을 쌓을 것이다.
우리가 설계를 하고 있다고 생각한다면,
우리는 설계를 하기 위해 생각할 것이고,
설계를 위한 지식과 스킬을 쌓을 것이다.
12. TDD 의 세가지 규칙
1. You are not allowed to write any production code unless it is to make a
failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to
fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to
pass the one failing unit test.
Robert C. Martin
13. TDD 는 왜 배우기 어려운가?
TDD 규칙은 간단하다.
그런데 배우기가 어렵다.
실천하기는 더 어렵다.
14. TDD 는 왜 배우기 어려운가?
TDD 는 설계 방법이다.
TDD 를 잘 하려면, 설계를 생각해야 하고
설계를 생각하려면,
설계 전문용어를 알아야 한다.
17. Design Feedback from TDD
TDD at the unit scale guides the design of the code to make the system easier to
modify, because it is easier to test code that is organised into loosely coupled, cohesive
units that have clear responsibilities.
My hunch is that TDD at the system scale works in a similar way, guiding the design
of the architecture to make the system easier to manage, because it requires the
system have machine-readable interfaces through which tools can observe and control
its activity.
( Growing Object Oriented Software guided by Tests, Steeve Freeman & Nat Pryce)