/**
아래의 글은 졸작에 힘쓰고 있는 후배들을 위해 조금이나마 도움이 될 수 있을까 싶어 학과 게시판에 올렸던 글이다.
요즘 블로그에 글을 한참 안올려서 이것이라도 올려본다. 하지만 나중에 다시한번 깨끗이 칼질을 해야 할듯하다..하지만 그게 언제가 될지는...
*/
아마도 컴공에서 공부를 하고 남는 결과중에 하나를 말하라고 한다면 졸작을 그중에 으뜸으로 꼽을 수 있을 것이다. 하지만 이 졸작이라는 것이 만드는 것이 만만치 않은 것이 대부분의 학생들이 학교를 다니면서 제대로된 프로젝트를 진행 해 본적도 없는데 나름 규모가 있는 작품을 만들어 내라고 한다.
// 어떻게 보면 대학 4년 동안 그럴싸한 프로젝트를 해 보지 않았다는 것이 슬픈이야기 이기도 하다..
그래서 나름대로 졸작을 하면서 느꼈던 경험들을 후배들을 위해서 주저리 주저리 말하고자 한다.
1. 팀원 구성(기한 미정)
대부분 졸작을 하기 위해서 마음 맞는 사람들과 팀을 구성하게 된다. 나름 프로그래밍 능력이 뛰어나고 마음 맞는 사람들 끼리 팀을 구성하면 가장 나이스한 상황이겠지만, 그것이 힘든 것이 현실이다. 다른 사람들의 실력에 짜증을 느끼고 혼자 개발 하겠다고 하는 사람도 있겠지만 인정과 위에서의 압박으로 혼자서 할 수 있는 경우는 별로 없다.
그래서 대부분 나름 프로젝트 경력이 있는 한 사람과 그 외 몇명으로 구성되는 것이 일반적이다.
그 외에 랩실에 있는 사람들끼리라던지, 동아리에 있는 사람들이라던지 서로 단체에 묶여서 같이 개발을 하는 경우도 있다. 이런 경우 서로 친하고 실력이 엇비슷한 사람끼리 한 조를 이룰 수 있는 확률이 높다.
2. 주제 선정(1주일 이내)
프로젝트 주제를 선정하고 그에 맞는 사람들을 모았다면 가장 좋겠지만, 대부분 사람을 먼저 모으고 주제를 선정한다. 이때 리더(보통 가장 프로그래밍 능력이 뛰어난 사람)의 의견에 수렴하여 프로젝트 주제가 결정 되곤 하는데 만일 마감기한이 촉박하다면 구현 가능성을 따져보고 리더의 의견에 따라가는 것이 좋지만 그렇지 않다면 리더는 회의를 열고 브레인스토밍등을 통해 다양한 주제를 후보에 올려 보는 것도 좋다.
일단 주제가 선정되고 나면 그 주제를 왜 해야만 하는지 이유를 만들어야 한다. 그냥 하고 싶어서, 공부에 도움이 될 것 같아서 등의 되지도 않는 이유를 대는 팀원이 있다면 이때 잘라 버려도 좋다. 리더가 그렇다면 그 팀을 어서 나오는 것이 정신건강에 좋다.
아무리 생각해 봐도 타당한 이유가 생각나지 않는다면 그 프로젝트는 졸작에서 통과 하기가 조금 힘들 것이라 생각된다. 주제를 다시 선정하라.
주제를 선정하고, 이유를 찾고, 타당하지 않다면 다시 주제를 선정하고 다시 이유를 찾는 과정을 반복하라. 대신 회의 시간이 너무 길어지면 팀원들이 지루해하고 피곤해 하여 막가라는 식으로 주제를 선정해버릴 수 있으므로 리더는 적절한 시간 안배를 하도록 주의 하여 팀원들의 집중력이 떨어 지지 않도록 해야한다.
이제 담당 교수님에게 보고 하러 간다.
3. 대망의 프로젝트 시작~!!
프로젝트를 시작한다고 코딩을 한다는 것은 아니다. 1번 항목에서도 언급 했지만 다들 프로그래밍 실력이 뛰어나다면 좋겠지만 그렇지 않은 경우가 태반이다. 그렇다고 프로그래밍 실력이 뛰어나지 않은 사람을 프로젝트에서 제외 할 필요는 없다. 프로젝트에는 프로그래밍 능력 뿐만 아니라 다른 많은 작업들이 포함 된다. 그 작업에 그 사람들을 사용하라. 회의 할때 그 사람들을 제외 시키지 말고 꼭 회의에 참석 시키라. 그 사람들에게 프로젝트의 전반적인 사항들을 항상 숙지 시키고 프로젝트를 바라보게 하라.
3.1 function spec(1주일)
주제가 정해지고 나면 프로그램에 무슨 기능이 필요한지를 회의하라. 구현에 대해서는 아직 신경쓰지 말라. 다시 한번 이야기 하지만 구현에 대해서는 절대 생각하지 말라. 쉽지 않겠지만 아직 구현에 대해서 신경쓸 단계는 아니다.
회의를 통해서 프로그램이 필요한 기능에 대해서 리스트를 작성하라. 한번의 회의를 통해서 모든 기능을 다 확정 지으려 하지마라. 약 일주일 정도의 시간을 가지고 매일매일 회의를 통해서 필요한 기능을 확정 지어라. 이 기능들은 나중에 하나의 함수로 정의 될 수도 있지만 아직은 단순히 프로그램이 가져야 할 기능일 뿐이다. 함수 처럼 만들려고 생각하지 마라.
기능이 확정되고 나면 이제 그 기능들 중에 정말 필요한 것과, 그렇지 않은 것들에 대한 우선순위를 정한다. 이 과정을 거치고 먼저 구현 해야 할 기능들과 그렇지 않은 기능들의 리스트가 만들어지게 된다. 이 과정을 거치고 나면 나중에 일정에 쫓길때 제외시켜야 할 항목들이 보다 분명해 진다.
애자일 개발 방법론에 보면 최대한 늦출 수 있을 때 까지 늦추라른 말이 있다. 여기서 이렇게 미리 모든 스펙을 정하고 간다는 것은 폭포수 개발 방법론에 보다 가깝다. 하지만 개인적인 견해로 폭포수 방법론은 해당 개발 프로세스에 아주 익숙해져 있고, 프로젝트 후반에 변동 사항이 적어야 한다는 제약 사항이 있다. 이 문서를 읽고 있을 여러분은 여러분이 진행하고 있는 프로젝트에 익숙하지 않은 사람이 대부분일 것이므로 추후 위의 기능들에 변동 사항이 있을 수도 있다는 가정을 하는 것이 좋을 것이다. 하지만 이 단계에서의 마음가짐만은 위의 기능에 대해 변동을 최소로 하겠다는 마음을 가져야 한다.
교수님에게 보고 하러 간다.
3.2 sequence diagram(1주일)
위의 과정에서 만들어진 기능들의 우선순위가 정해 졌다면 그 기능들을 어떻게 구현할 것인지에 대해서 생각해야 할 때가 왔다.
지금 부터는 그 기능들을 구현하기 위해서 어떠한 입력 값이 들어 오고 어떠한 과정을 통해서 결과가 도출 되는지를 결정해야 한다. 주의 할 사항은 아직 구체적인 구현에 대해서는 생각하지 말라. for문이 몇번 돌아야 하고, 클래스를 어떻게 구성 할 것이며, 어떤 프로토콜을 사용해야 할지 등에 대한 결정은 뒤로 미뤄 두라. 지금은 단지 한가지의 기능을 하기 위해서는 어떤 데이터들이 필요 하고 어떻게 가공해야 하는지만 생각하라.
예를 들어 서버에 로그인 하는 과정을 생각해 보자. 사용자는 아이디와 패스워드를 적고 로그인 버튼을 누르는 액션을 한다. 서버는 일단 사용자의 액션을 기다려야 하는 기능이 있어야 한다. 서버가 사용자가 액션을 했다는 것을 감지하면 서버는 이 사용자의 아이디와 패스워드가 맞는지를 확인 해야 하고, 맞다면 그에 해당하는 액션을, 그렇지 않다면 오류 메시지를 보내야한다.
1. 사용자의 입력 대기
2. 아이디 패스워드 검사
3.1 패스워드가 정확하다
3.1.1 로그인 성공 메시지를 보낸다.
3.2 패스워드가 부정확하다.
3.2.1 로그인 실패 메시지를 보낸다.
3.3 패스워드 실패가 3회 이상이다.
3.3.1 로그인 실패 메시지를 보낸다.
3.3.2 관리자에게 해킹 위험에 대한 경고 메시지를 보낸다.
3.3.3 패스워드을 임시 패스워드로 변경한다.
위의 시퀀스를 앞에 숫자를 주어 표현 해보았다. 이렇게 텍스트를 이용해서 표현해도 되지만 rose라던지 star UML등의 도구를 이용해 시각화 시켜 팀에서 공유하는 것이 같은 그림을 그리는데 있어서 상당한 도움이 된다.
그리고 여기까지는 특별한 프로그래밍 능력이 필요한 것이 아니라 논리적인 사고와 기억력만이 필요하므로 프로그래밍 능력이 떨어지는 팀원도 꼭 참석 시켜서 의견을 수렴하고, 프로젝트의 전반적인 사항들을 숙지 하도록 장려한다.
교수님께 보고 하러 간다.
3.3 Interface design(1주일)
이제는 이 기능들이 가져야 하는 모습을 확정 지어야한다. 위에서 시퀀스 다이어 그램을 작성하면서 하나의 시퀀스에 필요한 입력과, 그 과정을 통하면 나오는 결과에 대한 결정이 확정 되었을 것이다. 보통 이것을 '계약적 프로그래밍'이라고 하는데, 함수는 지정된 입력 값만을 받을 수 있으며, 그 입력들을 받았을 경우 기대되는 결과 값만을 리턴 해야만 한다는 것이다. 이렇게 함수에 입력과 출력의 형태가 정해져 있다면 나중에 나오는 테스트과정에 있어서 상당히 편해 진다.
이 여기서 산출되는 인터페이스들은 모든 팀원들이 반드시 같은 그림을 머릿속에 그려야 하고 숙지하고 있어야만 한다.
3.4 class diagram
이제는 필요한 기능과 인터페이스가 만들어 졌다. 이제부터는 프로그래밍 능력이 필요한 시간이 왔다. 이제 드디어 구현에 대해서 생각해 보자. 리더는 기능과 그 기능에 필요한 데이터들을 고려 하여 클래스다이어 그램을 그리도록 한다. 만일 C등 class를 지원하지 않는 다른 언어를 사용한다면 그에 맞겠금 디자인 하도록 한다. 이에 관련해서는 너무 방대한 내용이므로 여기서 다루지는 않겠다. 보다 관심있는 사람들은 디자인에 관련된 책들을 찾아 보기 바란다.
3.5 세부 구현
// 글이 길어지니 점점 내가 집중력이 떨어진다...
리더는 중요도가 높은 기능을 가진 클래스나 모듈부터 팀원들의 능력에 적절하게 배분하도록 한다. 하지만 하나의 프로그램을 두 명이상의 사람이 동시에 구현 하는 것은 그리 바람직한 방법이 아니다. 개발 진행의 동기화를 맞추기도 함들고 나중에 모듈을 합할때도 각각의 코딩 스타일때문에 쉽지 않다. 나름 개발 경험들이 있고, 코딩 스타일을 통일하는 경우라면 모를까 개발 경험이 그렇게 많지 않은 사람들이 서로의 코드를 합한다는 것은 한명이서 짤때 보다 더 많은 시간을 필요로 한다(그리고 오류가 발생 할 경우도 많다)
이왕이면 각 팀원들은 자신이 맡은 부분을 dll이나 lib으로 만들어 내도록 하고 그것이 불가피 할 경우(팀원들이 dll과 lib에 대한 기반지식이 없고 개발기간이 촉박할 경우)는 코드들을 통합하도록 한다.
그리고 개발을 할때는 3.3 과정에서 정의 한 인터페이스를 변경해서 구현하지 않도록 주의 한다. 불가피 하게 인터페이스의 수정이 필요할 경우는 전 팀원이 모인 가운데 회의를 통해 변경하고, 모든 사람들에게 공유하도록 한다. 그만큼 이 과정에서 인터페이스를 변경한다는 것은 상당히 까다로운 작업이라는 것이다.
개발자는 하나의 기능을 구현 할때 마다 단위 테스트를 통하여 그 기능에 대한 정당성을 입증해야만 한다.(단위 테스트에 관련된 내용은 Test driven developmonet라는 책을 참고 하도록한다)
이 과정에서 개발에 참여 하지 않는 팀원은 문서작업을 시작하도록 한다. 지금껏 만들어 졌던 function spec과 클래스 다이어그램 인터페이스 등을 종합하여 정리 하고, 프로그램의 사용법과 기타 ppt등을 준비하도록 한다.
교수님께 보고 하러 간다.
4. 테스트
위의 과정까지 코드를 생성하고 통합하는 과정까지 끝났다. 이제는 테스트를 하여 프로그램의 버그를 잡아야만 한다.
개발에 참여 하지 않았던 팀원을 주축으로 하여 프로그램을 테스트 하도록 한다. 기본적으로 function테스트라고 하여 문서에 명세된데로 사용 했을 경우 정상적으로 동작하는지를 테스트 하는 것이 있고 fault 테스트라고 하여 예외 상황이 발생 할 경우 프로그램이 어떻게 견디는지를 알아보는 테스트가 있다.
개발에 참여 하지 않았던 인원들은 위의 사항을 생각하여 테스트 시나리오를 작성하여 팀원들과 협의한다.
협의된 대로 테스트를 진행하며 테스트 도중 버그가 발생하면 바로 개발 팀에게 통보하여 바로바로 디버깅을 시도하도록 한다. 일정이 촉박하고 도저히 디버깅이 될 가능성이 보이지 않는 기능이 있다면 기능의 중요 여부에 따라 제외 시키는 것도 가능하다. 이렇게 해서 기능에 변화가 있다면 회귀 테스트를 통해 수정된 코드가 정상적으로 동작하는를 매번 확인해야만 한다.
모든 테스트가 끝났다면 교수님께 보고 하러 간다.
그리고 주변의 지인들을 동원에 아무런 사전 지식도 없는 상태에서 프로그램을 테스트 하도록 한다. 그리고 버그가 발생하지 않는다면 메뉴얼을 보여 주고 사용상 어려운 점이 있는지를 테스트 한다.
이러한 과정을 통해 새로 추가 되어야 할 기능과 변경되어야 할 기능들을 정하도록 하고 TODO로 남겨 두거나 이전의 개발 과정을 되밟도록 한다.
테스트와 관련된 좀 더 자세한 내용은 [넋두리있다] - 테스트 시나리오 작성 방법 를 참고 하도록 한다.
이상으로 개인적인 경험을 통해서 간략(?)하게 개발 방법에 대해서 이야기 해보았다. 처음에는 자세하게 하게 하나 하나 예를 들어 가면서 설명하고자 했지만 분량도 장난이 아니고 시간이 가다보니 집중력이 떨어져서 내용이 많이 부실해 졌다. 나중에 반응 좋으면 위에서 나왔던 개발 방법론들에 대해서도 글을 올려 보도록 하겠다.ㅋㅋ
//아...첨에 별생각 없이 적었는데 넘 길다..-,.-, 읽느라고 수고 하셨습니다.
2007/08/03 - [진리는어디에] - Coding Tip
아래의 글은 졸작에 힘쓰고 있는 후배들을 위해 조금이나마 도움이 될 수 있을까 싶어 학과 게시판에 올렸던 글이다.
요즘 블로그에 글을 한참 안올려서 이것이라도 올려본다. 하지만 나중에 다시한번 깨끗이 칼질을 해야 할듯하다..하지만 그게 언제가 될지는...
*/
아마도 컴공에서 공부를 하고 남는 결과중에 하나를 말하라고 한다면 졸작을 그중에 으뜸으로 꼽을 수 있을 것이다. 하지만 이 졸작이라는 것이 만드는 것이 만만치 않은 것이 대부분의 학생들이 학교를 다니면서 제대로된 프로젝트를 진행 해 본적도 없는데 나름 규모가 있는 작품을 만들어 내라고 한다.
// 어떻게 보면 대학 4년 동안 그럴싸한 프로젝트를 해 보지 않았다는 것이 슬픈이야기 이기도 하다..
그래서 나름대로 졸작을 하면서 느꼈던 경험들을 후배들을 위해서 주저리 주저리 말하고자 한다.
1. 팀원 구성(기한 미정)
대부분 졸작을 하기 위해서 마음 맞는 사람들과 팀을 구성하게 된다. 나름 프로그래밍 능력이 뛰어나고 마음 맞는 사람들 끼리 팀을 구성하면 가장 나이스한 상황이겠지만, 그것이 힘든 것이 현실이다. 다른 사람들의 실력에 짜증을 느끼고 혼자 개발 하겠다고 하는 사람도 있겠지만 인정과 위에서의 압박으로 혼자서 할 수 있는 경우는 별로 없다.
그래서 대부분 나름 프로젝트 경력이 있는 한 사람과 그 외 몇명으로 구성되는 것이 일반적이다.
그 외에 랩실에 있는 사람들끼리라던지, 동아리에 있는 사람들이라던지 서로 단체에 묶여서 같이 개발을 하는 경우도 있다. 이런 경우 서로 친하고 실력이 엇비슷한 사람끼리 한 조를 이룰 수 있는 확률이 높다.
2. 주제 선정(1주일 이내)
프로젝트 주제를 선정하고 그에 맞는 사람들을 모았다면 가장 좋겠지만, 대부분 사람을 먼저 모으고 주제를 선정한다. 이때 리더(보통 가장 프로그래밍 능력이 뛰어난 사람)의 의견에 수렴하여 프로젝트 주제가 결정 되곤 하는데 만일 마감기한이 촉박하다면 구현 가능성을 따져보고 리더의 의견에 따라가는 것이 좋지만 그렇지 않다면 리더는 회의를 열고 브레인스토밍등을 통해 다양한 주제를 후보에 올려 보는 것도 좋다.
일단 주제가 선정되고 나면 그 주제를 왜 해야만 하는지 이유를 만들어야 한다. 그냥 하고 싶어서, 공부에 도움이 될 것 같아서 등의 되지도 않는 이유를 대는 팀원이 있다면 이때 잘라 버려도 좋다. 리더가 그렇다면 그 팀을 어서 나오는 것이 정신건강에 좋다.
아무리 생각해 봐도 타당한 이유가 생각나지 않는다면 그 프로젝트는 졸작에서 통과 하기가 조금 힘들 것이라 생각된다. 주제를 다시 선정하라.
주제를 선정하고, 이유를 찾고, 타당하지 않다면 다시 주제를 선정하고 다시 이유를 찾는 과정을 반복하라. 대신 회의 시간이 너무 길어지면 팀원들이 지루해하고 피곤해 하여 막가라는 식으로 주제를 선정해버릴 수 있으므로 리더는 적절한 시간 안배를 하도록 주의 하여 팀원들의 집중력이 떨어 지지 않도록 해야한다.
이제 담당 교수님에게 보고 하러 간다.
3. 대망의 프로젝트 시작~!!
프로젝트를 시작한다고 코딩을 한다는 것은 아니다. 1번 항목에서도 언급 했지만 다들 프로그래밍 실력이 뛰어나다면 좋겠지만 그렇지 않은 경우가 태반이다. 그렇다고 프로그래밍 실력이 뛰어나지 않은 사람을 프로젝트에서 제외 할 필요는 없다. 프로젝트에는 프로그래밍 능력 뿐만 아니라 다른 많은 작업들이 포함 된다. 그 작업에 그 사람들을 사용하라. 회의 할때 그 사람들을 제외 시키지 말고 꼭 회의에 참석 시키라. 그 사람들에게 프로젝트의 전반적인 사항들을 항상 숙지 시키고 프로젝트를 바라보게 하라.
3.1 function spec(1주일)
주제가 정해지고 나면 프로그램에 무슨 기능이 필요한지를 회의하라. 구현에 대해서는 아직 신경쓰지 말라. 다시 한번 이야기 하지만 구현에 대해서는 절대 생각하지 말라. 쉽지 않겠지만 아직 구현에 대해서 신경쓸 단계는 아니다.
회의를 통해서 프로그램이 필요한 기능에 대해서 리스트를 작성하라. 한번의 회의를 통해서 모든 기능을 다 확정 지으려 하지마라. 약 일주일 정도의 시간을 가지고 매일매일 회의를 통해서 필요한 기능을 확정 지어라. 이 기능들은 나중에 하나의 함수로 정의 될 수도 있지만 아직은 단순히 프로그램이 가져야 할 기능일 뿐이다. 함수 처럼 만들려고 생각하지 마라.
기능이 확정되고 나면 이제 그 기능들 중에 정말 필요한 것과, 그렇지 않은 것들에 대한 우선순위를 정한다. 이 과정을 거치고 먼저 구현 해야 할 기능들과 그렇지 않은 기능들의 리스트가 만들어지게 된다. 이 과정을 거치고 나면 나중에 일정에 쫓길때 제외시켜야 할 항목들이 보다 분명해 진다.
애자일 개발 방법론에 보면 최대한 늦출 수 있을 때 까지 늦추라른 말이 있다. 여기서 이렇게 미리 모든 스펙을 정하고 간다는 것은 폭포수 개발 방법론에 보다 가깝다. 하지만 개인적인 견해로 폭포수 방법론은 해당 개발 프로세스에 아주 익숙해져 있고, 프로젝트 후반에 변동 사항이 적어야 한다는 제약 사항이 있다. 이 문서를 읽고 있을 여러분은 여러분이 진행하고 있는 프로젝트에 익숙하지 않은 사람이 대부분일 것이므로 추후 위의 기능들에 변동 사항이 있을 수도 있다는 가정을 하는 것이 좋을 것이다. 하지만 이 단계에서의 마음가짐만은 위의 기능에 대해 변동을 최소로 하겠다는 마음을 가져야 한다.
교수님에게 보고 하러 간다.
3.2 sequence diagram(1주일)
위의 과정에서 만들어진 기능들의 우선순위가 정해 졌다면 그 기능들을 어떻게 구현할 것인지에 대해서 생각해야 할 때가 왔다.
지금 부터는 그 기능들을 구현하기 위해서 어떠한 입력 값이 들어 오고 어떠한 과정을 통해서 결과가 도출 되는지를 결정해야 한다. 주의 할 사항은 아직 구체적인 구현에 대해서는 생각하지 말라. for문이 몇번 돌아야 하고, 클래스를 어떻게 구성 할 것이며, 어떤 프로토콜을 사용해야 할지 등에 대한 결정은 뒤로 미뤄 두라. 지금은 단지 한가지의 기능을 하기 위해서는 어떤 데이터들이 필요 하고 어떻게 가공해야 하는지만 생각하라.
예를 들어 서버에 로그인 하는 과정을 생각해 보자. 사용자는 아이디와 패스워드를 적고 로그인 버튼을 누르는 액션을 한다. 서버는 일단 사용자의 액션을 기다려야 하는 기능이 있어야 한다. 서버가 사용자가 액션을 했다는 것을 감지하면 서버는 이 사용자의 아이디와 패스워드가 맞는지를 확인 해야 하고, 맞다면 그에 해당하는 액션을, 그렇지 않다면 오류 메시지를 보내야한다.
1. 사용자의 입력 대기
2. 아이디 패스워드 검사
3.1 패스워드가 정확하다
3.1.1 로그인 성공 메시지를 보낸다.
3.2 패스워드가 부정확하다.
3.2.1 로그인 실패 메시지를 보낸다.
3.3 패스워드 실패가 3회 이상이다.
3.3.1 로그인 실패 메시지를 보낸다.
3.3.2 관리자에게 해킹 위험에 대한 경고 메시지를 보낸다.
3.3.3 패스워드을 임시 패스워드로 변경한다.
위의 시퀀스를 앞에 숫자를 주어 표현 해보았다. 이렇게 텍스트를 이용해서 표현해도 되지만 rose라던지 star UML등의 도구를 이용해 시각화 시켜 팀에서 공유하는 것이 같은 그림을 그리는데 있어서 상당한 도움이 된다.
그리고 여기까지는 특별한 프로그래밍 능력이 필요한 것이 아니라 논리적인 사고와 기억력만이 필요하므로 프로그래밍 능력이 떨어지는 팀원도 꼭 참석 시켜서 의견을 수렴하고, 프로젝트의 전반적인 사항들을 숙지 하도록 장려한다.
교수님께 보고 하러 간다.
3.3 Interface design(1주일)
이제는 이 기능들이 가져야 하는 모습을 확정 지어야한다. 위에서 시퀀스 다이어 그램을 작성하면서 하나의 시퀀스에 필요한 입력과, 그 과정을 통하면 나오는 결과에 대한 결정이 확정 되었을 것이다. 보통 이것을 '계약적 프로그래밍'이라고 하는데, 함수는 지정된 입력 값만을 받을 수 있으며, 그 입력들을 받았을 경우 기대되는 결과 값만을 리턴 해야만 한다는 것이다. 이렇게 함수에 입력과 출력의 형태가 정해져 있다면 나중에 나오는 테스트과정에 있어서 상당히 편해 진다.
이 여기서 산출되는 인터페이스들은 모든 팀원들이 반드시 같은 그림을 머릿속에 그려야 하고 숙지하고 있어야만 한다.
3.4 class diagram
이제는 필요한 기능과 인터페이스가 만들어 졌다. 이제부터는 프로그래밍 능력이 필요한 시간이 왔다. 이제 드디어 구현에 대해서 생각해 보자. 리더는 기능과 그 기능에 필요한 데이터들을 고려 하여 클래스다이어 그램을 그리도록 한다. 만일 C등 class를 지원하지 않는 다른 언어를 사용한다면 그에 맞겠금 디자인 하도록 한다. 이에 관련해서는 너무 방대한 내용이므로 여기서 다루지는 않겠다. 보다 관심있는 사람들은 디자인에 관련된 책들을 찾아 보기 바란다.
3.5 세부 구현
// 글이 길어지니 점점 내가 집중력이 떨어진다...
리더는 중요도가 높은 기능을 가진 클래스나 모듈부터 팀원들의 능력에 적절하게 배분하도록 한다. 하지만 하나의 프로그램을 두 명이상의 사람이 동시에 구현 하는 것은 그리 바람직한 방법이 아니다. 개발 진행의 동기화를 맞추기도 함들고 나중에 모듈을 합할때도 각각의 코딩 스타일때문에 쉽지 않다. 나름 개발 경험들이 있고, 코딩 스타일을 통일하는 경우라면 모를까 개발 경험이 그렇게 많지 않은 사람들이 서로의 코드를 합한다는 것은 한명이서 짤때 보다 더 많은 시간을 필요로 한다(그리고 오류가 발생 할 경우도 많다)
이왕이면 각 팀원들은 자신이 맡은 부분을 dll이나 lib으로 만들어 내도록 하고 그것이 불가피 할 경우(팀원들이 dll과 lib에 대한 기반지식이 없고 개발기간이 촉박할 경우)는 코드들을 통합하도록 한다.
그리고 개발을 할때는 3.3 과정에서 정의 한 인터페이스를 변경해서 구현하지 않도록 주의 한다. 불가피 하게 인터페이스의 수정이 필요할 경우는 전 팀원이 모인 가운데 회의를 통해 변경하고, 모든 사람들에게 공유하도록 한다. 그만큼 이 과정에서 인터페이스를 변경한다는 것은 상당히 까다로운 작업이라는 것이다.
개발자는 하나의 기능을 구현 할때 마다 단위 테스트를 통하여 그 기능에 대한 정당성을 입증해야만 한다.(단위 테스트에 관련된 내용은 Test driven developmonet라는 책을 참고 하도록한다)
이 과정에서 개발에 참여 하지 않는 팀원은 문서작업을 시작하도록 한다. 지금껏 만들어 졌던 function spec과 클래스 다이어그램 인터페이스 등을 종합하여 정리 하고, 프로그램의 사용법과 기타 ppt등을 준비하도록 한다.
교수님께 보고 하러 간다.
4. 테스트
위의 과정까지 코드를 생성하고 통합하는 과정까지 끝났다. 이제는 테스트를 하여 프로그램의 버그를 잡아야만 한다.
개발에 참여 하지 않았던 팀원을 주축으로 하여 프로그램을 테스트 하도록 한다. 기본적으로 function테스트라고 하여 문서에 명세된데로 사용 했을 경우 정상적으로 동작하는지를 테스트 하는 것이 있고 fault 테스트라고 하여 예외 상황이 발생 할 경우 프로그램이 어떻게 견디는지를 알아보는 테스트가 있다.
개발에 참여 하지 않았던 인원들은 위의 사항을 생각하여 테스트 시나리오를 작성하여 팀원들과 협의한다.
협의된 대로 테스트를 진행하며 테스트 도중 버그가 발생하면 바로 개발 팀에게 통보하여 바로바로 디버깅을 시도하도록 한다. 일정이 촉박하고 도저히 디버깅이 될 가능성이 보이지 않는 기능이 있다면 기능의 중요 여부에 따라 제외 시키는 것도 가능하다. 이렇게 해서 기능에 변화가 있다면 회귀 테스트를 통해 수정된 코드가 정상적으로 동작하는를 매번 확인해야만 한다.
모든 테스트가 끝났다면 교수님께 보고 하러 간다.
그리고 주변의 지인들을 동원에 아무런 사전 지식도 없는 상태에서 프로그램을 테스트 하도록 한다. 그리고 버그가 발생하지 않는다면 메뉴얼을 보여 주고 사용상 어려운 점이 있는지를 테스트 한다.
이러한 과정을 통해 새로 추가 되어야 할 기능과 변경되어야 할 기능들을 정하도록 하고 TODO로 남겨 두거나 이전의 개발 과정을 되밟도록 한다.
테스트와 관련된 좀 더 자세한 내용은 [넋두리있다] - 테스트 시나리오 작성 방법 를 참고 하도록 한다.
이상으로 개인적인 경험을 통해서 간략(?)하게 개발 방법에 대해서 이야기 해보았다. 처음에는 자세하게 하게 하나 하나 예를 들어 가면서 설명하고자 했지만 분량도 장난이 아니고 시간이 가다보니 집중력이 떨어져서 내용이 많이 부실해 졌다. 나중에 반응 좋으면 위에서 나왔던 개발 방법론들에 대해서도 글을 올려 보도록 하겠다.ㅋㅋ
//아...첨에 별생각 없이 적었는데 넘 길다..-,.-, 읽느라고 수고 하셨습니다.
2007/08/03 - [진리는어디에] - Coding Tip
