"이거 전에 잘 되던건데 왜 안되죠?"
개발자를 당혹케하는 질문중에 하나이다. 난 분명 관련 내용을 수정한 적이 없는데(다른 부분에 수정한건 있지만) 머지?
만약 높은 사람 앞에서 데모 중이었거나 출시를 코앞에 두고 위와 같은 질문이 들어온다면 아마 대부분 머리속이 하얘질 것이다.
도데체 어디서부터 어느 부분에서 문제가 된걸까?
우리는 버전 관리 시스템을 통해 구현 히스토리를 모두 검토해볼수 있다. 혹은 과거의 버전으로 돌릴수도 있다.
이제부터 꼬이기 시작한다. 그리고 계속 버전을 헤맨다.
분명 다른데서 문제의 원인을 발생시킨걸거야.. 내 문제가 아니라는 것을 증명해야되.. 피해갈 구멍만 찾는다.
문제가 발생했을때 가장 먼저 해야 할일은 문제를 정의하는 것이다.
이전에 잘 되었던것은 다른 문제다. 현재 안되는것이 문제이다. 문제를 잘못 정의 했을때 우리는 삽질을 한다.
자신이 삽질로 야근이나 밤샘 중에 있다면 다시한번 생각해보는 것이 좋다. 내가 고치고자 하는 문제가 정확히 무엇인지..
아직도 과거의 히스토리를 뒤질 차례는 아니다. 다음에 해야할일은 문제를 분석하는 것이다.
문제를 발생하는 원인에 대해서 정확히 파악해야 한다. 그 후에 히스토리를 참고 하던 내 문제가 아님을 증명하던 이실직고 하고 수정하건지 하면된다.
의외로 이런 과정을 천천히 제대로 진행하면 어떻게하면 빨리 이 상황을 벗어날까 조마조마 하면서 삽질하는 것보다 굉장히 빠르게 문제를 정확히 해결 할 수 있다.
그리고 아마 재발하지 않을 것이다. 재발 하더라도 본인 문제가 아닐 것이다.
소프트웨어 개발 생산성은 코딩 속도에서 오지 않는다.
회사도 마찬가지다. 중요한건 현재의 에티튜드..
Trackback | http://sozu.tistory.com/trackback/47
파일럿 프로젝트와 Top-Down 방식의 리팩토링
Agile Experience / 2011/02/14 09:00
프로젝트 초반, 그리고 설계
상위설계(High Level Design)는 일반적으로 프로젝트 초반에 작성됩니다. 상위설계는 해당 프로젝트의 결과물의 근간이 되기 때문에 매우 중요하며 크게 변하는 경우는 드뭅니다. 어디까지나 상위설계이기 때문이죠. 뜬구름 잡는 얘기일 수도 있기 때문에 기술적으로 아주 세세하게 알지 못해도 작성할수 있는 경우가 있습니다. 하지만 상세설계(Low Level Design)에 접어들게 되면 구체적으로 많은 선택을 해야합니다. 골치 아프죠.
많은 경우에 어느 수준까지 작성해야 할지 갈피를 못잡고 방황하다가 적당히 보고 수준의 문서를 작성하고 구현에 들어갑니다. 결국 구현 따로 상세설계 따로인 결과물이 탄생하게 됩니다.
유지보수와 스파게티 코드 양산
유지보수중 스파게티 코드를 양산하게 되는 경우중 하나는 소스코드만 가지고 문제 해결을 할수 밖에 없는 경우 입니다. 아마 대부분의 경우가 이러할꺼라 생각됩니다. 근본적으로 문제를 해결하고 싶지만 근본적인 원인을 찾는데 도움이 될수 있는 큰 그림을 볼 수 있는 단서가 유지보수 단계에까지 남아있는 경우가 드물죠. 결국 기존 소스를 분석하다 지쳐서 땜빵코드를 삽입할수 밖에 없는 경지에 이릅니다. 제가 아는 대부분의 개발자는 땜빵코드를 삽입하는 것에 대해 부정적이지만 어쩔수 없이 하는 경우가 많습니다. 물론 저를 포함해서..
파일럿 프로젝트로 시작하는 '동작하는' 프로젝트
앞에서도 말씀드렸지만 상세설계를 어느 수준까지 작성해야할지 고민되는 경우가 많습니다. 저는 이를 해결하기 위해 프로젝트 초반에 파일럿 프로젝트를 진행합니다. 어떤 레퍼런스를 쓰던 일단 원하는 결과물을 얻기 위해 이것 저것 시도해보며 최종적으로 해당 기능들을 간신히 수행하는(하지만 있을건 다있는) '동작하는' 소스코드를 만들어 냅니다. 그리고 이것을 통해 프로젝트를 본격적으로 시작할때부터 '동작하는' 소스코드를 가지고 시작할 수 있게 합니다. 그리고 현재 수준에서 껍데기(Front-End) 바로 아래부분(Top)부터 추상화(Abstraction)을 통한 인터페이스 추출(Interface Extraction) 작업을 시작합니다. 추출된 인터페이스를 정리하면 매우 간단한(Class가 몇개 안되는) Class Diagram과 Sequence Diagram을 그릴수 있습니다. 이것이 상세설계서의 0.01 버전이 될수 있겠습니다. 이를 바탕으로 리팩토링을 하게 되면 인터페이스 추출이 완료된 상위 클래스를 제외하고는 나머지는 뚱땡이 클래스가 되어있겠죠. 이제 시작입니다.
Top-Down으로 진행되는 리팩토링, 그리고 지속적인 설계
리팩토링을 Top-Down으로 하게 되면 소스코드의 리팩토링 단위가 커지게 되므로 보통은 추천하지 않습니다. 하지만 설계는 Top-Down으로 할수록 깔끔해집니다.(제 의견입니다.) 가장 상위(Top)부터 시작하여 단계적으로 하위(Bottom)까지 진행되는 인터페이스 추출은 리팩토링을 지속적으로 하도록 유도합니다. 그리고 리팩토링된 소스코드는 항상 '동작하는' 상태여야 합니다. 그리고 결과물인 소스코드와 UML 문서는 최소 1명의 팀원과 리뷰를 합니다. 반복하다보면 뚱땡이 클래스들이 점점 분리되여 계층적인 클래스 구조를 만들게 될겁니다. 고럼 다음과 같은 프로세스가 만들어 집니다.
주기는 짧을 수록 좋다
저는 위의 주기를 하루에 최소 한번 할수 있도록 개발 계획을 수립합니다. (작은 마일스톤으로 쪼개는 방법은 다음에 써보도록 하겠습니다.) 그나마 주기가 짧아야 리팩토링 단위와 정리해야할 UML 문서의 단위가 작아집니다.
결과적으로 얻을 수 있는건..
- 항상 '동작하는' 소스코드
- 항상 정확하게 현재 소스코드를 큰 그림으로 파악(Static and Dynamic!)할 수 있는 딸랑 2종류의 UML Diagram
- 새로운 기능 넣기 전에 UML Diagram 으로 검토하는 습관...
- 바쁜 이슈처리 상황에서 근본적으로 문제해결을 할 수 있는 여유..
- 객체지향적 설계 능력?ㅡㅡ;;
그런데 결국은 뭐라도 해봐야..뭐가 다른지 압니다.
'Agile Experience' 카테고리의 다른 글
| 파일럿 프로젝트와 Top-Down 방식의 리팩토링 (2) | 2011/02/14 |
|---|---|
| 우리 개발팀은 어디로 가고 있을까? (2010 NHN Deview 회고) (6) | 2010/09/14 |
| 창의적인 아이디어는 어디에서 오는가? (4) | 2010/09/12 |
| UML을 이용한 점진적 설계와 구현 (짧은 경험담) (0) | 2010/09/01 |
Trackback | http://sozu.tistory.com/trackback/46
-
2011/02/17 18:33
Subject: 잘못된 설계와 빙산 클래스(Iceberg Classes)
우연히 레거시코드 활용전략(Working effectively with legacy code)의 저자 마이클 C 페더스가 2005년에 쓴 글을 읽게됐습니다. 일부만 옮겨봤습니다. 잘못된 설계를 식별하는 방법에는 여러가지가 있다. 그중에서 늘 내가 강조하는 것은 public 메소드가 private 메소드보다 훨씬 적어야 한다는 원칙이다. 즉 클래스는 빙산과 같아야 한다. public 메소드가 한두개가 수면에 떠있다면 그 밑에 많은 private 메소드..
삭제Tracked from 실용주의이야기(Pragmatic Story)
우리 개발팀은 어디로 가고 있을까? (2010 NHN Deview 회고)
Agile Experience / 2010/09/14 10:35
지난주에 현업과는 관련이 없어 보이는 NHN에서 주관하는 개발자 컨퍼런스에 참석하였습니다.
업무에 직접적인 관련이 없다보니 영감이 늦게 밀려드는가 봅니다. 이제서야 회고를 해봅니다. (발표 내용에 대한 후기는 없답니다.ㅋ)
NHN은 어디로 가고 있나?
Deview가 끝나고 난 느낌은 "NHN은 이렇게 잘 하고 있구나" 정도였습니다. 솔직히 그 이상도 이하도 아니었습니다.
후기 경품이 탐이 났지만 딱히 쓸말이 없었습니다. 싸이트 가면 동영상이 모두 공개 되어있는데 후기를 쓰자니 거시기 했습니다.
그러던중 문득 이런 생각이 들었습니다. 왜 키노트 스피치를 좀 지루할 정도로 구구절절히 길게 하였을까?
제가 추측한 이유는 NHN이 가고 있는 목표에 대해서 진심으로 구구절절히 공유하고 싶었기 때문입니다.
키노트 스피치가 끝난 후에 지인중 한분이 그러더군요. "그냥 애자일 한다고 하면 되지 않나?"
분명 NHN에서 하고 있는 활동들은 애자일스러웠습니다. 하지만 애자일이 NHN의 목표가 아니기 때문에 궂이 애자일을 한다고 할 필요가 없었던 것이라고 생각합니다.
이러한 관점으로 Deview의 강연들을 생각해보니 NHN이 가고자 하는 곳이 어디인지가 보이더군요.^^
그곳이 어디인지 제가 자세히 기술할수는 없지만 분명한건 NHN 내부 개발자만을 위한 천국은 아닐겁니다.
궂이 애자일 조직이라고 표현할 필요가 없다.
가끔 애자일을 짝 프로그래밍이나 테스트 주도개발, 스크럼등의 Best Practice로 여기시는 분들이 많습니다.
혹은 갓 입사한 회사나 팀에서 애자일을 모른다고, 애자일 팀이 아니라고 실망하는 신입 개발자분들도 있습니다.
수단과 목표가 약간 혼동되는 부분이라고 생각합니다. 애자일도 목표는 아니라고 생각합니다.
꼭 개발조직에 애자일이나 RUP, Waterfall, CMMI 등의 정체성이 명시적으로 존재해야 할까요? 그런건 정치판에서도 지겨운데...
우리가 원하는건 애자일 조직이 아니라 행복하게 개발할 수 있는 매우 효율적인 개발 조직일겁니다. (정확히 말하면 제가 원하는 것입니다^^)
물론 조직에 맞는 애자일스런 Practice를 만들어나가면 좀더 빠르게 그런 조직을 만들수 있을것입니다.
제가 말하고 싶은건 뭘 하면 애자일이고 안하면 애자일이 아니다 이런게 중요한게 아니다라는 것입니다.^^;;
개인적으로 '애자일'이란 표현보다 '실용적인'이란 표현이 더 좋습니다.ㅋ
이런 점에서 NHN의 발표에서 '애자일'이란 용어를 쓰지 않은 것은 현명한 선택이었다고 생각합니다.
기대되는 NHN의 행보
얼마전까지만 해도 NHN은 뒤뚱거리는 거대한 한국의 포털 기업으로만 생각했었습니다. 개발에 열정을 가졌던 친구가 NHN의 신입사원으로 입사한 후에 개발의 열정이 식어버린... 그냥 포털 대기업으로만 생각했었습니다.
하지만 Deview를 보면서 생각이 조금 바뀌었습니다. 열악한 한국의 개발 환경을 불평, 불만만 하는 사람들이 변화될 수 있도록 기여하는 기업이 되고 있다고 생각합니다. (우리 회사도 그런 기업이 될겁니다!^^)
스스로 바뀌어야 환경도 바뀝니다.^^
이상 짧은 회고였습니다;... 회고라기 보다는 주저리주저리 떠든;;ㅋ
NHN Deview 2010 동영상 다시 보기 및 자료 : http://deview.naver.com/2010/courses.nhn
'Agile Experience' 카테고리의 다른 글
| 파일럿 프로젝트와 Top-Down 방식의 리팩토링 (2) | 2011/02/14 |
|---|---|
| 우리 개발팀은 어디로 가고 있을까? (2010 NHN Deview 회고) (6) | 2010/09/14 |
| 창의적인 아이디어는 어디에서 오는가? (4) | 2010/09/12 |
| UML을 이용한 점진적 설계와 구현 (짧은 경험담) (0) | 2010/09/01 |
댓글을 달아 주세요
저도 가끔 문제를 정확히 파악하는데 집중을 하지않고 어떻게든 다른 핑계를 찾는 개발자를 보곤합니다.
그러면 삽질로 가는 지름길인데...
저도 그중에 하나 일지도..@@ 안타깝죠ㅠㅠ