Embed Size (px)
Citation preview
우리가 하는 일을 정의해 보자?
우리가 하는 일은 무엇인가?
우리가 하는 일은?
Implementation is the act of Coding?
Implementation is not the act of Coding?
http://c2.com/cgi/wiki?WhatIsSoftwareDesign
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 )
Design Documentation
http://wonju.kopo.ac.kr/bbs/board.php?bo_table=m31_05&wr_id=2
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 )
우리가 하는 일은?
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
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 )
우리가 하는 일은?
Design
Coding vs Design
우리가 코딩을 하고 있다고 생각한다면,
우리는 코딩을 하기 위해 생각할 것이고,
코딩을 위한 지식과 스킬을 쌓을 것이다.
우리가 설계를 하고 있다고 생각한다면,
우리는 설계를 하기 위해 생각할 것이고,
설계를 위한 지식과 스킬을 쌓을 것이다.
TDD 사이클
http://www.natpryce.com/articles/000780.html
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
TDD 는 왜 배우기 어려운가?
TDD 규칙은 간단하다.
그런데 배우기가 어렵다.
실천하기는 더 어렵다.
TDD 는 왜 배우기 어려운가?
TDD 는 설계 방법이다.
TDD 를 잘 하려면, 설계를 생각해야 하고설계를 생각하려면,
설계 전문용어를 알아야 한다.
설계와 관련된 용어들
알고 있는 설계 관련 용어들을 적어보자.
언제 설계를 하나요?
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)
여전히 TDD 는 배우기가 어렵다.
왜?
