프로그램을 만들어 가는 과정. 2. 만들어보자!

저번 주 한번 쉬고 다시 올라오는 포스트군요.

익스플로러가 미쳐버려서 글 올리는데 시간이 좀 걸리지 싶습니다.

겨우 텍스트 몇자 끄적이는데 렉이 걸리다니... ㄱ-

----------------------------------------------------------------------------------------

프로그래머가 프로그램을 만들기 위해 일단 계획을 하여 설계를 한다,

이게 저번 포스트의 내용이었지요.

예압~ 설계를 하면 개발에 돌입해야지요?

프로그램의 개발 방식에는 여러가지가 있습니다.

1. 팀 개발

2. 개인 개발

.......

농담이구요.

-_-

1. TDD(Test Driven Development)

2. 애자일 방법론

3. 모듈 분할 방법

..... 뭐 이름이 거창하기들 하긴 하다만

사실 셋다 비슷합니다.

첫번째 TDD부터 소개하도록 하지요.

1. TDD(Test Driven Development)

TDD방식은 "테스트 주도 개발"이라 하여, 아주 사소한 뼈대부터 하나하나 만들어다가

살을 붙이고 붙여나가면서 개발하는 방식입니다.

프로그래밍을 공부할 때 자주 쓰이는 방식이지요.

실제 개발에서는 어쩔런지 잘 모르겠습니다만... 개인규모에서 쓰면 딱 좋고,

구조가 조금씩 기괴하게 만들어질 수도 있습니다.

가령 예를 들어... 계산기를 만든다 합시다.

#include <stdio.h> int main() { int a, b; scanf("%d%d", &a, &b); printf("%d\n", a + b); }

일단 가장 기본적인 구현인 덧셈을 구현합니다.

그리고 잘 돌아가는지 테스트합니다.

#include <stdio.h> void input(int *a, int *b) { scanf("%d%d", a, b); } void output(int *a) { printf("%d\n", *a) } int main() { int a, b, result; input(&a, &b); result = a + b; output(result); }

잘 돌아갑니다.

근데 덧셈만 해선 안됩니다.

출력부와 입력부를 함수로 분리시킵니다.

#include <stdio.h> void input(int *a, int *b) { scanf("%d%d", a, b); } void output(int *a) { printf("%d\n", *a) } int select(int *a, int *b) { int c; printf("연산 타입 결정하세요(1 : 덧셈, 2 : 곱셈, 3 : 뺄셈, 4 : 나눗셈)\n"); scanf("%d", &c); if (c == 1) { return *a + *b; } else if (c == 2) { return *a * *b; } else if (c == 3) { return *a - * b; } else if (c == 4) { return *a / *b; } else { printf("그런 연산은 존재하지 않습니다. 종료합니다.\n"); exit(1); } } int main() { int a, b, result; input(&a, &b); result = select(&a, &b); output(result); }

자, 연산부분 또한 함수로 만들어서 선택권을 사용자에게 넘깁니다.

여기서 우리는 각 부분을 하나하나 테스트하며 프로그램의 덩치를 조금씩 키워나갔고,

이에 따라 해당 테스트 파트 하나를 교체함으로서

기능을 교체하거나 업그레이드 시킬 수 있습니다.

"뼈대가 글러먹은" 경우만 아니라면 말이지요.

가령 예를 들자면 이 코드를 "수식 연산"이 가능하게 하려면

완전히 갈아엎어야 하지요. -ㅁ-;;;

2. 애자일 방법론

애자일은 Agile이라고 영어로 씁니다.

뭐... Light-weight 방법론이 근원이라고 하는데요.

"기민하다" 혹은 "가볍다" 라는 의미이지요.

하나의 소규모 팀에서 적용하기에 좋은 방법입니다.

각자의 팀원이 한개의 부분 분할 모듈을 맡고,

이에 자신의 파트에 열중합니다.

다른 모듈에 신경쓰지 않고 말이지요.

가령 예를 들자면..

A, B, C, D의 네명으로 이루어진 팀이 있고,
이 네명의 팀원이 각각 "로드", "컨트롤", "세이브", "뒷정리" 파트를 분할담당한다.

이 정도의 시나리오게 되겠군요.

각자의 파트를 가볍게 처리해서 해당 파트를 연결해 나가는 겁니다.

3. 모듈 분할 방법

어느 정도 규모 이상의 팀에서 쓸 수 있습니다.

혹은 개인 개발에서도 가능하고, 대규모, 소규모팀 상관 없습니다.

다만, 소규모팀이라면 적용에서 좀 머리가 아파오지요.

이전 포스트에서도 소개했듯,

프로그램은 "모듈의 집합" 입니다.

이 방법은 각 팀원이 각자 모듈을 맡는다는 점이 위의 방법들과 비슷하나,

2.의 애자일과 좀 다르다면 기민하지 않다는것이 차이점입니다.

아래와 같은 시나리오가 되겠군요.

A라는 팀원부터 Z라는 팀원까지 26명의 팀원이 있고,

A부터 F까지는 실력이 가장 뛰어난 팀원들이다.

이에 따라 A부터 F까지는 최하위 모듈들의 개발을 맡으며,

G부터 Z까지 팀원들은 순차적으로 실력이 낮아진다.

아키텍쳐 1인이 구조를 설계하고,

좀 더 높은 레벨의 모듈(다른 모듈들을 사용하는 모듈)의 개발을 G부터 순서대로 할당한다.

최하위 바로 위의 모듈은 G부터 J까지가 맡으며,

최종 모듈 조립은 Z가 아키텍쳐와 함께 한다.

최하위 바로 위의 모듈들은 A부터 F까지의 팀원이 개발한 최하위 모듈들의 조립이고,

Z가 조립할 부분은 이미 만들어진 모든 최종 모듈들의 조립으로 프로그램을 완성하는 과정이다.

우후. 대충 이렇게 됩니다.

프로젝트 리더의 역할이 중요하지요.

아무리 A가 실력이 좋더라도 꼬장부리면

전체 팀의 개발에 문제가 생기니까요.

또한 Z가 말 안듣고 "아 몰라 못해" 하고 배 째도 문제가 생기겠지요?-_-;

이 외에도 수많은 개발방법론이 존재합니다만,

사실 다들 모듈에 기반한다는 점에서 얼추 비슷합니다.

------------------------------------------------------------------------------------------------

다음 포스트에서는 실제 프로그램을 만들어 보면서 진행하고 싶지만...

입대가 코앞인지라 "프로그램의 확장성"에 대해서 언급하고 이 시리즈를 마무리 짓도록 하겠습니다.

이후는 C++의 제네릭 프로그래밍에 대해 시리즈를 시작하도록 하지요.

-_-!