> 들어가기전 잡담
어제는 친한 친구와 약속이 있었고, 오늘도 친구와 약속이 있었는데 모두 취소가 되었습니다. 허탈한 마음을 뒤로하고 투표를 하고 서점에 갔다가 집에 왔습니다.
이쯤 되면 시간도 남고 제가 한방 포스팅이라고 부르는 블로깅을 할 수도 있었는데 블로깅도 리듬을 타는 것 같습니다. 이제 회사일 바빠져서 블로깅 천천히 하겠다고 쓴 글이 무안하게 얼마전에는 글을 많이 쓴다 싶더니만 이번주는 글쓰기에 손이 가질 않았습니다.
머릿속에 떠오르는 글감중 최근 경험담이 담긴 간단한 글을 쓰면서 다시 닻을 올리고 항해(=블로깅)를 해야겠습니다.
> 본문
에러는 잡힌다. 짧은 경력이지만 내가 아는 에러는 완전히 죽진 않더라도, 잡히지 않은 적은 없었다. 그러나 에러를 잡는 과정은 잃어버린 지갑을 찾는 것처럼 언제나 나(=개발자)를 속 태운다.
A모듈을 개발했다. A모듈은 시간이란 자원이 넉넉하게 주어져서 나는 침착하게 개발 할 수 있었다. 내가 생각할 수 있는 발생가능한 모든 에러 발생 경우의 수를 테스트 자동화 클래스(=JUnit 프레임워크)로 만들어서 테스트를 했더니, 지금까지 문제가 발생하지 않았다. 다행히 A모듈은 튼튼하게 키우기 사작했다.
B모듈을 개발했다. B모듈은 다른 시스템 자원하고 같이 돌아가기 때문에(=네트워크 모듈) 발생 가능한 모든 경우의 수를 생각할 수 있더라도, 그 경우의 수에 대하여 테스트 자동화 하기는 어려웠다. 그래서 ‘이러면 되겠지~’ 하고 개발한 부분이 있었는데 최근에 다양한 경우에서 에러가 뻥뻥~ 터져나왔다.
회사 선배와 같이 붙어서 에러를 해결해 나갔다. 에러가 거의 해결되는 과정에서 회사 선배가 이렇게 말씀하셨다.
산골 선배 : “그럴 가능성은 거의 없겠지만..B1에러 상황도 혹시 있을까..아니 없을꺼야..산골아 이정도 잡았으면 되겠지?”
산골 대리 : (흠..B1에러 상황도 혹시 터질수도 있겠지만..아마도 그럴 일은 없을것 같다..) “흠흠..넵..처리 것 같아요.”
산골 선배 : 산골아 그럼 다른 문제는 혹시 없을까? 이렇게 하고 마무리 할까?
산골 대리 : (흠흠..그럴 가능성은 희박하지만..B2에러 상황도 있을수도 있는데..아니야..B2에러가 터질리는 없겠지..) “네 이정도 다듬었으면 된 것 같은데요..인자..마무리 하고 퇴근하시죠. 헤헤~ ^ ^”
산골 대리 : (흠..B1에러 상황도 혹시 터질수도 있겠지만..아마도 그럴 일은 없을것 같다..) “흠흠..넵..처리 것 같아요.”
산골 선배 : 산골아 그럼 다른 문제는 혹시 없을까? 이렇게 하고 마무리 할까?
산골 대리 : (흠흠..그럴 가능성은 희박하지만..B2에러 상황도 있을수도 있는데..아니야..B2에러가 터질리는 없겠지..) “네 이정도 다듬었으면 된 것 같은데요..인자..마무리 하고 퇴근하시죠. 헤헤~ ^ ^”
그런데 얼마 후 우리의 대화를 무시하고 너무도 당당하게 B1, B2 에러가 뻥뻥~ 터졌다. 다시 에러를 잡기 시작했다.
이렇게 안 좋은 경우로 에러를 잡자 이번에는 발생 가능한 모든 에러 발생 경우의 수를 엑셀 파일로 정리하여 하나하나 다시 테스트 하기로 했다. 엑셀 파일로 정리하여 하나하나 수작업으로 테스트 했더니 예상 못했던 한두가지 문제가 더 발생됐고 이 문제들을 해결하면서 일단 B모듈 처리는 마무리 한 상태이다.
이번 경험들은 사실은 항상 반복하여 경험하는 것들이라서 다시 한번 정리가 필요하다는 생각을 했다. 귀차니즘을 이겨내고 튼튼한 프로그램 개발을 위해 이 글로 마음을 가다듬는다.
> 에러 잡는 마음가짐 (내 마음대로 정리한..)
1. 개발하다가 마음속으로 ‘그럴리 없겠지만 혹시 A문제가 터지지 않을까..’ 라는 신호는 미리 에러를 감지해주는 고마운 신호다.
2. ‘이 정도면 되겠지~’를 감으로 증명하지 말고 증거자료로 증명하자.
3. 가장 좋은 에러 검증 증거자료는 JUnit 프레임워크로 테스트 자동화 하는 것이다.
4. 테스트 자동화가 불가능하다면 엑셀 파일등의 문서로 가능한 모든 에러 발생 경우의 수를 정리하여 테스트 하자.
5. 에러는 잡힌다. 에러 잡는 초조한 순간에는 이 생각을 하며 마음을 차분하게 가다듬자.
2. ‘이 정도면 되겠지~’를 감으로 증명하지 말고 증거자료로 증명하자.
3. 가장 좋은 에러 검증 증거자료는 JUnit 프레임워크로 테스트 자동화 하는 것이다.
4. 테스트 자동화가 불가능하다면 엑셀 파일등의 문서로 가능한 모든 에러 발생 경우의 수를 정리하여 테스트 하자.
5. 에러는 잡힌다. 에러 잡는 초조한 순간에는 이 생각을 하며 마음을 차분하게 가다듬자.
덧1) 혹시 위의 에러 잡는 마음가짐 말고 또 없을까요? 고수 개발자님들의 피드백 부탁드립니다. ^ ^
'개발자 > 칼럼' 카테고리의 다른 글
| TCP/IP 책 3종 세트를 읽고 (네트워크 프로그래밍) (27) | 2008/04/23 |
|---|---|
| 자바 NIO 네트워크 프로그래밍 공부 (11) | 2008/04/17 |
| 에러 잡는 마음가짐 (8) | 2008/04/09 |
| IBM developerWorks 리뷰 블로거들과의 만남 (10) | 2008/04/05 |
| 개발자와 프로그래밍의 가치을 높여주는 JUnit (8) | 2008/04/03 |
| Grails 마스터하기 (IBM developerWorks) (4) | 2008/03/28 |
댓글을 달아 주세요
요즘 읽고 있는 책내용중에 결함검사 테스트를 이야기하면서 '결함주도개발'이라는 용어에 대하여 언급하더군요. 갑자기 생각이 나서..뜬금없는 댓글을..ㅎㅎ 좋은 하루 보내세요.
엇..인상좋으신 열이아빠님 안녕하세요.
테스트주도개발TDD 와는 다른 개념의 개발방식인가요.
한번 구글 검색 해봐야 겠네요. ^ ^
전...개발자가 만든 것들만 쓰는 부류라..패스를 ㅠㅠ
어휴..그래도 찾아주시는 네슬리님..정말
싸랑합니다. ^ ^;
예전에 나돌았던 프로그래머 10계명에... 9번째 항목에 이런 말이 있었죠..
9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은 항상 바보와 미친놈만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라.
.. 바X와 미친X가 쓰더라도 에러없이 작동할 정도의 프로그램을 만들면 되지 않을까 하는 생각이... 쿨럭..
바X와 미친X가 쓰더라도 에러없이 작동할 정도의 프로그램을 만들 '궁극의 경지'에 도달한 프로그램 개발을 위해
메직보이님과 저..항상 화이팅 입니다.~! ^ ^
참..블랙잭 정말 좋은것 같아요. 무지 잘쓰고 있어요. ^ ^
이쯤이면 충분하지 하는 순간
알수없는 에러가 펑펑..........
적당히 풀린다면 나름대로 재미있는 에러.^^
전 초보개발자라 공감만 할뿐입니다 ^^
섬세한 여성 프로그래머분들이 에러는 잘 잡을것 같다눈~