2007/07/07 08:20 Developer
비즈니스 로직과 의존성을 줄이는 사례
최근 블로그에 비즈니스 로직의 복잡성와 의존성에 대한 이야기를 많이 적었는데, 마침 업무를 진행중에 재미있는 일이 발생을 했다.
우리 팀에 초보 개발자인 막내는 경력이나 경험에 비해서 센스가 꽤 있는 편이다.
그 초보 개발자가 어느날부터 jakarta-POI를 열심히 API를 익히면서 코딩을 하고 있었다. 간단한 API이기때문에 빠른 시간에 습득해서 잘 사용하고 있었다.
어제 코드리뷰 시간에 그 내용에 대해서 언급을 하는 자리가 있었는데, 아주 흥미로운 일이 벌어졌다..^^
초보 개발자가 구현해야 할 업무는 테스트로 진행되고 있는 데이터를 실디비로 마이그레이션을 하는 업무였다. 한번 쓰고 내다버릴 배치성 업무였다.
2가지의 문제가 거론이 되었는데, 이것이 흥미롭다.
우리는 개발을 진행을 하다보면 과다 설계과 디자인의 홍수 속에서 살게 된다.
과연 이렇게까지 해야만 할까? 이게 정말 옳은 일인까? 수많은 고민을 하게 된다.
dependency가 많고 코드량이 많으면 버그가 증가할 수 밖에 없다. 최소주의의 코딩이 절실하게 필요하다. 최소주의 코딩은 당연한 이야기지만, testability도 확연히 좋아진다.
문제의 해결점은 최대한 비즈니스 로직을 심플하게 정리를 하고(개발에 쓰는 머리에 5%만 사용을 해도 단순하게 바꿀수 있다) 여러가지 문제 해결 방법이 있다면, 가능한 의존성이 적은 구현, 테스트를 하기 쉬운 구현으로 생각을 해보자
당연한 이야기지만, 의존성이 적을 수록 테스트하기는 쉬워 질 것이다.
갑자기 테스트가 웬말이라는 사람이 있을까봐 한줄 더 적는다..^^
우리 팀에 초보 개발자인 막내는 경력이나 경험에 비해서 센스가 꽤 있는 편이다.
그 초보 개발자가 어느날부터 jakarta-POI를 열심히 API를 익히면서 코딩을 하고 있었다. 간단한 API이기때문에 빠른 시간에 습득해서 잘 사용하고 있었다.
어제 코드리뷰 시간에 그 내용에 대해서 언급을 하는 자리가 있었는데, 아주 흥미로운 일이 벌어졌다..^^
초보 개발자가 구현해야 할 업무는 테스트로 진행되고 있는 데이터를 실디비로 마이그레이션을 하는 업무였다. 한번 쓰고 내다버릴 배치성 업무였다.
2가지의 문제가 거론이 되었는데, 이것이 흥미롭다.
1. 테스트 DB에서 데이터를 가져와서 자바빈에 바인딩을 하고 그것을 다시 실디비에 데이터를 넣고 있었다. 중간에 DTO를 십분 활용을 하는 것이다.
어쨌든 우리가 가장 일반적으로 사용하는 방법이다.
하지만,
EP님이 조언을 해주셨다. 약간의 생각만 바꾸어도 코드량이 줄어들뿐만 아니라 의미없는 코드로 노가다를 하는 작업이 대량 줄어들었다.
2. 초보개발자는 기획자가 엑셀로 데이터를 줄 것으로 예상을 했다. 엑셀에서 키값 데이터를 읽어서 그것을 처리하는 방식으로 개발을 한 것이다.
기획자뿐만 아니라 우리 나라 직장인은 엑셀을 선호하는 경향이 있다. 아마 구현을 하기전에 그렇게 준다고 커뮤니케이션을 했을 수도 있다. 리뷰를 시작하면서 테스트 엑셀 파일을 열었는데, 컬럼 2개에 데이터가 있었다. 정말 심플한 데이터였다. 이것을 CSV로 변환을 해서 단순하게 text파일을 읽어서 구분자(,)로 구분해서 데이터를 읽었더라면, POI 라이브러리 의존성도 없이 구현이 가능했을 것이다. 같이 리뷰하던 고수의(?) 개발자분들은 이구동성으로 얘기를 했다. 물론 자주 사용되는 어플리케이션이라 CSV로 바꾸는 것 조차 귀찮다고 한다면, POI를 이용한 어플리케이션이 더 빛을 발할수도 있었겠지만, 이번 건은 CSV로 넣는 것이 더 좋은 선택으로 보인다.
실제로 전에 있던 회사에서 업무를 진행할 때 CSV로 넣었던 import데이터를 엑셀도 추가로 가능하게 구현한 적도 있다. 그 때는 엑셀으로 임포트가 명확한 요구사항이고, 자주 사용하던 기능이었다.
어쨌든 우리가 가장 일반적으로 사용하는 방법이다.
하지만,
한번 밖에 호출되지 않은 심플한 로직과 업무처리에서 굳이 빈에 담아서 어렵게 할 필요없이 컨넥션을 2개 열어서 ResultSet에서 바로 loop를 돌면서 실디비로 데이터를 이관을 할수 있을 것이다.
EP님이 조언을 해주셨다. 약간의 생각만 바꾸어도 코드량이 줄어들뿐만 아니라 의미없는 코드로 노가다를 하는 작업이 대량 줄어들었다.
2. 초보개발자는 기획자가 엑셀로 데이터를 줄 것으로 예상을 했다. 엑셀에서 키값 데이터를 읽어서 그것을 처리하는 방식으로 개발을 한 것이다.
기획자뿐만 아니라 우리 나라 직장인은 엑셀을 선호하는 경향이 있다. 아마 구현을 하기전에 그렇게 준다고 커뮤니케이션을 했을 수도 있다. 리뷰를 시작하면서 테스트 엑셀 파일을 열었는데, 컬럼 2개에 데이터가 있었다. 정말 심플한 데이터였다. 이것을 CSV로 변환을 해서 단순하게 text파일을 읽어서 구분자(,)로 구분해서 데이터를 읽었더라면, POI 라이브러리 의존성도 없이 구현이 가능했을 것이다. 같이 리뷰하던 고수의(?) 개발자분들은 이구동성으로 얘기를 했다. 물론 자주 사용되는 어플리케이션이라 CSV로 바꾸는 것 조차 귀찮다고 한다면, POI를 이용한 어플리케이션이 더 빛을 발할수도 있었겠지만, 이번 건은 CSV로 넣는 것이 더 좋은 선택으로 보인다.
실제로 전에 있던 회사에서 업무를 진행할 때 CSV로 넣었던 import데이터를 엑셀도 추가로 가능하게 구현한 적도 있다. 그 때는 엑셀으로 임포트가 명확한 요구사항이고, 자주 사용하던 기능이었다.
우리는 개발을 진행을 하다보면 과다 설계과 디자인의 홍수 속에서 살게 된다.
과연 이렇게까지 해야만 할까? 이게 정말 옳은 일인까? 수많은 고민을 하게 된다.
dependency가 많고 코드량이 많으면 버그가 증가할 수 밖에 없다. 최소주의의 코딩이 절실하게 필요하다. 최소주의 코딩은 당연한 이야기지만, testability도 확연히 좋아진다.
문제의 해결점은 최대한 비즈니스 로직을 심플하게 정리를 하고(개발에 쓰는 머리에 5%만 사용을 해도 단순하게 바꿀수 있다) 여러가지 문제 해결 방법이 있다면, 가능한 의존성이 적은 구현, 테스트를 하기 쉬운 구현으로 생각을 해보자
당연한 이야기지만, 의존성이 적을 수록 테스트하기는 쉬워 질 것이다.
갑자기 테스트가 웬말이라는 사람이 있을까봐 한줄 더 적는다..^^
