본문 바로가기

카테고리 없음

팀원에게 객제지향 개발을 유도하기 (2/3)

팀원에게 객제지향 개발을 유도하기 (1/3) 에 이어서 포스팅 합니다.

> 왜 JUnit등의 테스팅 프레임워크를 이용하여 테스트 클래스를 만들어야 되는거죠?


보통 버그를 어떻게 잡으시나요.
1. 대충 테스트 하고 '이 정도면 되겠지 아마 에러 안날꺼야~' 라고 낙관하거나
2. 에러나면 그때 처리하자고.. 라고 낙관하거나
3. 그래도 이부분은 에러 없어야 되니 100가지 경우를 몽땅 '수작업'으로 테스트 하는거야..

대개 이러지 않을까요. 그런데 이런 경우는 생각만 해도 아찔합니다. 보호망 없이 외줄타기 하는것과 같고, 망망대해에서 손으로 물고기 잡는것과 마찬가지이고, 로봇으로 자동 제작하던 공장 제품을 갑자기 수작업으로 제작하는 것과 마찬가지입니다.

JUnit은 외줄타기 하는 개발자를 추락으로부터 보호해주는 보호망과 같고, 버그를 잡아주는 저인망 그물과 같으며, 자동으로 공장 제품을 만들어주는 로봇과 같습니다.

일단 발생가능한 모든 에러의 경우를 테스트 클래스 통해 미리 값을 셋팅하고 우리가 의도한 결과가 나오나 테스트를 합니다. 예를들어 ‘전화 걸기’ 메소드를 호출하면 ‘전화 신호음 발생’ 기능이 제대로 리턴되는지 테스트 하는 것처럼요. 개발자의 노력과 재량에 따르겠지만 촘촘하게 테스트 클래스를 만들수록 버그 잡는 완벽한 그물이 될 것입니다.

저는 특히 3.번의 경우를 경험하고 JUnit의 위력을 실감했습니다. 제가 개발하는 특정 모듈은 너무도 중요해서 에러 발생하면 큰일 나거든요. 그래서 일일이 수작업으로 테스트 해야 했습니다. 그런데 100가지면 100가지를 모두 버튼 하나로 자동으로 테스트 할 수 있게 만들어 놓으면 다음부터는 JUnit 실행 버튼 하나로 100가지 테스트를 자동으로 할 수 있습니다. 반드시 수행해야하는 100가지 테스트를 수작업으로 하는 것과 자동으로 하는 것과의 차이를 한번 비교해보세요. 자동으로 100가지 경우를 테스트 하는 것이 엄청난 이득입니다.

다른 유익한 점은 내부 기능에 이것저것 변화를 주었을 때 입니다. 갑자기 내부 소스를 크게 바꿔야 되는 일이 생겼다면, 튼튼해야될 댐에 보이지 않는 균열이 생기듯 나도 모르게 의도하지 않는 부분에 영향을 주어 없던 버그를 만들어 냅니다. 그런데 이때 JUnit 테스트를 한번 쫘악~ 돌리면 바로 에러를 뱉어줍니다. 이렇게 JUnit는 개발자와 제품의 안전을 보장해주는 저인망 버그잡이 어선~ 입니다.

그리고 또 하나 유익한 점은, JUnit 활용시 나무보다 숲을 보는 프로그래밍 즉 내부 로직보다 인터페이스 설계에 집중하는 프로그래밍을 할 수 있습니다. 기타 JUnit 활용시의 장점을 체계적으로 정리한 포스팅은,
개발자와 프로그래밍의 가치을 높여주는 JUnit 을 참고하여 주시길 바랍니다.

사용자 삽입 이미지


>
성능 VS 유지보수라면 빨리 개발하고 빠른 성능 봐야 되는 우리 입장에서 성능을 고려해야 되지 않을까?

일단 결과물을 빨리 내야 하고 빠른 성능을 보여줘야 한다면 성능이 중요하겠지만, 요즘처럼 하드웨어가 발달하고 각 언어 플랫폼이 거의 동등한 성능을 보장하는 요즈음에는, 성능 요소보다는 유지보수 요소가 더 중요하다고 생각합니다.

유지보수가 편하다는 것은 결국 회사 비용이 많이 절감된다는 것이고 이 절감된 비용을 하드웨어 확장 등에 사용한다면 훨씬 바람직한 성능향상을 볼 수 있겠죠.

그리고 유지보수가 편하다는 것은 개발이 튼튼하게 진행됐다는 것으로 빠른 성능보다도 우선시 되는 안정성에서도 높은 점수를 받을 수 있습니다.

그래서 무작장 빨리 개발하면서 빠른 성능을 보장하는 것 보다는 유지보수 편리함을 지향하기 위해 프레임워크등을 사용하는 것이 좋을 것 입니다.


+ 다음편에서는..

1편에서는,
> 스프링 프레임워크 좋기는 한것 같은데.. 우리 나름대로 개발하는게 더 편하고 더 빨리 개발할 수 있으면 프레임워크 없이 써도 되는거 아닐까?
> 객체지향스럽게 짜야 되는 이유는 무엇일까, 그리고 객체지향 스럽게 짠다는 의미가 어떤 의미지?

2편에서는,
> JUnit 등으로 테스트 클래스를 만들면 왜 좋은거죠?
> 성능 VS 유지보수라면 빨리 개발하고 빠른 성능 봐야 되는 우리 입장에서 성능을 고려해야 되지 않을까.
까지 다뤘고요.

3편에서는
> 잠깐, 왜 인터페이스와 인터페이스를 상속하는 구현체를 만드는 식으로 프로그래밍 해야 하는 거죠?
> 스프링 프레임워크에 실제로 레거시 코드(예전에 짠 소스)를 어떻게 이식했는가..

의 의문에 대한 제 나름대로의 답을 쓸 예정입니다.
고수 개발자분들의 피드백 부탁드립니다. ^ ^


덧1) 산골 블로그의 관련글
팀원에게 객제지향 개발을 유도하기 (1/3)

에러 잡는 마음가짐
개발자와 프로그래밍의 가치을 높여주는 JUnit

추상화의 고수가 되자. (생각의 탄생)
객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?)

한국스프링사용자모임2회(KSUG) 참가 후기 (스프링 달인의 한수 가르침)
한국스프링사용자모임3회(KSUG) 참가 후기 (자리잡은 커뮤니티)
한국스프링사용자모임4회(KSUG) 참가 후기 (AOP)
한국스프링사용자모임5회(KSUG) 참가 후기 (웹플로우(WebFlow), 보안(Acegi))

덧2) IBM developerWorks의 관련글

JUnit4가 최근에 나왔습니다. 자바5 부터 추가된 기능인 annotation태그를 활용하여 기존의 엄격한 명명규칙 및 상속 계층 구조를 앲애면서 유연성을 향상시켰다고 합니다. 다만 예전 JUnit 버전을 쓰신분이라면 조금 햇갈리시겠죠. IBM developerWorks의 아래 튜토리얼 기사를 통해 JUnit4의 편리한 기능과 사용방법을 배워보시길 바랍니다.