서락 엔터테인먼트(?)

한글이 참 어려운 말인가 봅니다.

리포트를 받는데, 맞춤법 맞지 않는 것은 그렇다 치지만...

최소한 말이 되는지는 본인이 써보고 한번쯤은 읽어봐야 한다고 생각합니다.

리포트도 뭐 좋다 이겁니다. 경영진 참조 걸어서 메일 쓸 때 만이라도 제발...

...읽고 해석이 가능할 정도로만 써주세요...



...최소한 제가 차후에 면접을 본다면 업무 관련해서 우선 묻겠지만 한글 시험을 꼭 봐야 한다고 생각합니다.

...그래서 위의 뻘글을 정리하자면




입사 면접에 한글 시험을 도입하라!!

1.    TDD(Test-Driven Development)의 궁극적인 목적

1)      작동하는 깔끔한 코드(clean code that works)

 

2.    TDD의 규칙

1)      오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.

2)      중복을 제거한다.

 

3.    TDD 규칙이 갖는 기술적인 함의

1)      매 결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 해야 한다.

2)      자동화된 테스트를 다른 사람이 만들어주길 기다릴 수 없으므로, 직접 테스트를 만들어야 한다.

3)      개발 환경은 작은 변화에도 빠르게 반응할 수 있어야 한다.

4)      테스트를 쉽게 만들려면 반드시 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게끔 설계하여야 한다.

 

4.    TDD 규칙에 의한 TDD의 프로그래밍 순서

1)      빨강 - 실패하는 테스트를 작성. 컴파일조차 되지 않을 수 있다.

2)      초록 - 최대한 빨리 테스트를 통과할 수 있는 코드를 작성. 이를 위해 어떠한 죄악을 저질러도 상관없음

3)      리펙토링 - 테스트를 통과하게 만드는 과정에서 생겨난 모든 중복 코드를 제거

 

5.    TDD가 갖는 사회적 함의

1)      결함 밀도를 충분히 감소시킬 수 있다면, 품질보증을 수동적 -> 능동적 작업으로 전환 가능

2)      치명적인 예외 상황의 숫자를 충분히 낮출 수 있다면, 프로젝트 매니저가 (일정 혹은 개발 정도를) 정확히 추정할 수 있어 고객을 매일의 개발 과정에 참여시킬 수 있음 (괄호 안은 임의로 추가 - 책 내용이 말이 이상해서-_-;;)

3)      기술적 대화의 주제가 충분히 분명해진다면, 소프트웨어 엔지니어들은 일일 혹은 주 단위의 협력 대신 분 단위로 협력하면서 일할 수 있음

4)      결함 밀도가 충분히 낮아질 경우, 새로운 기능이 추가 가능한 소프트웨어를 갖게 되고, 이를 통해 고객과 새로운 비지니스 관계에 이를 수 있음

 

6.    TDD에서의 두려움이 제공하는 것(이러한 두려움은 어떠한 것도 프로그래밍에 도움되지 않음)

1)      망설이게 만듬

2)      커뮤니케이션을 덜 하게 만듬

3)      피드백 받는 것을 피하도록 만듬

4)      까다롭게 만듬(지랄맞은 성격)

 

7.    TDD의 두려움에 맞서는 방법

1)      불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 하기 시작함

2)      침묵을 지키는 대신, 좀 더 적극적이고 분명하게 커뮤니케이션을 함

3)      피드백을 회피하는 대신, 좀 더 도움이 되고 구체적인 피드백을 찾음

4)      (자신의 나쁜 성격은 직접 해결해야 함)

여기까지가 TDD에 관한 기초적인 설명입니다.

좀 더 심화된 부분 부터는, 다음 글에 알맞은 예제를 들어 설명하도록 하겠습니다.

근데 이거 저작권에 걸리는거 아닐...라나 싶지만 책을 그대로 갖다 붙인 것도 아니고 나름대로 제가 정리한 것이니 별 무리는 없을 것으로 생각합니다. 문제 생기면 지우죠 뭐.

모든 내용은 테스트 주도 개발(TDD(Test-Driven Devlopment) By Example)이라는 책의 내용 중 일부임을 밝힙니다.

PS. 책에 예제가 Java로 되어있어서 C/C++로 컨버팅 할라면 죽어날듯[...]