Architecture

제목을 조금 자극적으로 써봤습니다.여러분은 테스트코드란 무엇이라고 생각하시나요?제가 소프트웨어 엔지니어로 일을 시작하고나서, 저에게 가장 큰 깨달음을 준건 "테스트코드" 입니다.대부분의 회사에 그렇듯 제가 재직중인 회사에도 Legacy 프로젝트가 존재합니다.여전히 Core 한 로직들이 Legacy 프로젝트에서 동작중이죠. 최근에 작성된 프로젝트들의 경우에는 테스트코드 커버리지가 꽤 높습니다.하지만, Legacy 프로젝트의 경우 테스트코드 커버리지가 거의 0에 가까웠습니다. Legacy 프로젝트는 코드를 읽고 완전한 로직을 파악하기까지 꽤나 많은 시간이 필요합니다. 코드가 서로 얽혀있고, 모듈화 되지 않았기 때문입니다. 그리고 통합 테스트 도구의 부족으로 FeatureTest, 그리고 UnitTest 조차..

Trade-Off(구조의 안정성 vs 단순한 개발의 편리성) 스프링 데이터 JPA 예제를 수행한 것을 다시 한번 돌아보며, 느낀 것들을 기록한다. 우선, DI, OCP를 지키기 위해 어댑터를 도입한 코드의 클래스 의존 관계와, 런타임 객체 의존 관계를 살펴보자. 중간에서 JpaItemRepositoryV2가 어댑터 역할을 해준 덕분에 ItemService가 사용하는 ItemRepository 인터페이스를 그대로 유지할 수 있고, 클라이언트인 ItemService의 코드를 변경하지 않아도 되는 장점이 있다. 그런데, 여기서 고민이 생긴다. 구조를 맞추기 위해서, 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단점이 생겼다. 실제 이 코드를 구현해야하는 개발자 입장에서 보..

Querydsl을 이용한 리팩토링 (feat. 쿼리 조각화) Querydsl을 공부하다가, 예제코드를 보고, 당연한 것임에도 정말 좋은 방법이다 라는 생각이 들어서 글을 남긴다. Before Refactoring Code 리팩토링을 하기 전의 코드다. Querydsl을 이용하여 동적쿼리를 작성한 코드다. 만약 검색 조건으로 들어온 itemName이 like검색을 수행하고, 없으면 like 검색을 하지 않고, 만약 검색 조건으로 들어온 maxPrice가 null이 아니면 and 조건을 달아서 >= maxPrice 를 수행하고, null이면 안하는 이러한 로직이다. 그런데, 여기서 조금더 코드를 개선했더니 많은 이점을 얻을 수 있었다. 우선, 리팩토링한 코드를 보자. After Refactoring Code..

최근에 백엔드 공부를 시작하면서, 재미있는 하루하루를 보내고 있다. 스프링을 이용해서 간단한 회원관리서비스를 만들었는데, 정말 간단한 프로젝트여도 얻은 것이 정말 많은 프로젝트였다. 특히나 설계의 중요성을 다시한번 깨닫는 개발이었다. 서비스의 비즈니스 요구사항 요약하자면, 이름을 설정하여 회원가입 존재하는 회원의 이름과 같은 이름으로는(중복 이름) 가입 불가 아직 데이터 저장소가 선정되지 않은 상태(가상의 시나리오) 이러한 비즈니스 요구사항을 가정하고 만든 서비스이다. 회원의 이름 데이터를 저장하는 저장소가 아직 선정되지 않았기에, MemberRepository라는 이름으로 인터페이스를 만들고, 처음에는 간단하게 자체 메모리에 저장하도록 MemoryMemberRepository라는 이름으로 구현체를 작성..