나는 현재 mybatis를 사용하며 절차지향적인 개발을 하고 있다. 그 과정에서 내가 sql에 의존하는 개발에 대하여 느낀 경험을 전달한다.
절차지향적 개발은 DB와 쿼리에 매우 의존적이다. 특히 select 쿼리를 짜는데 있어서 개발자가 의도가 다 들어간다. 그 데이터는 DTO로 생성한다. 해당 객체는 어떤 기능도 가지지 않고 그저 데이터를 전달하는 목표만을 부여받는다.
객체가 DTO 수준으로 역할을 부여받듯 MVC 패턴 역시 DTO로 전락한다. select으로 생성한 쿼리를 적당하게 가공하는 역할에 불과하며, MVC 자체는 일종의 규칙에 불과하다.
컨트롤러는 jsp나 api로 전달 받은 데이터를 검증하는 역할로 한정된다. 컨트롤러나 리포지토리 한 쪽에서만 처리하기 애매해거나 다수의 컨트롤러에서 사용할 만한 공통 메서드를 처리하는 수준으로 역할이 한정된다. 컨트롤러 메서드 하나가 하나의 서비스 메서드만 사용하면 차라리 낫다. 그러나 어설프게 공통 서비스 메서드를 사용하는 순간 그 메서드는 수정하기 두려워 지는 순간이 될 때까지 무한정으로 길어진다.
자바 또한 db의 통신을 위해 존재하는 dto로서의 기능으로 위상이 추락한다. 물론 java.lang java.util java.io 등 기본 api와 스케줄러, 스레드, 트랜잭션 등 자바 스프링이 제공하는 다양한 기능을 익힌다. 하지만 이는 자바의 기능을 사용할 뿐, 객체지향 개발이나 개발의 새로운 패러다임과는 크게 관계가 없다.
jpa는 많은 영감을 줬다.
최근 나는 김영한 개발자님의 JPA에 대한 강의를 다시 듣고 학습했다. 1년 전에 공부했을 때는 나는 jpa가 왜 객체지향적인 개발인지 이해하지 못했다. mybatis와 무슨 차이가 있는지를 몰랐다. 1년 안되는 짧은 경력이 아주 조금 있다고, jpa를 공부하면서 절차지향적 개발과 객체지향적 개발의 차이가 무엇인지를 어렴풋이 느끼게 되었다.
JPA가 객체지향적인 개발을 가능케 하는 이유는 (내 소박한 의견으로는) 영속성 컨텍스트에 있다고 생각한다. 영속성 컨텍스트에 소속된 객체는 어디에 있든 영속성을 보장받는다. 객체와 컬렉션을 우리는 jvm.getHeap.save() 메서드에 넣지 않는다. 영속성에 신경쓰지 않고 자유롭게 개발한다. 절차지향적 개발을 할 때는 명확한 방향성이 존재한다. 그러니까 dto를 리포지토리에서 컨트롤러로 혹은 컨트롤러에서 리포지토리로의 방향성이 있고, 개발자는 이로부터 벗어날 수 없다.
JPA는 방향이 없다. map에서 객체를 꺼내듯, 영속성 컨텍스트에 있는 객체를 꺼내고 변경하고 냅두면 알아서 저장된다. insert, update 쿼리로 완성시키기 위한 방향성으로부터, 자바 엔티티를 어떻게 조합할까로 나의 고민이 바뀐다. jpa가 있는 순간 절차지향적 개발을 할 수밖에 없다는 변명은 더는 통하지 않게 된다. 나는 자연스럽게 좋은 개발을 위한 고민을 하게 되었다.
좀 더 좋은 테스트 코드를 작성하고 싶었다.
TDD를 학습하게 된 계기는 (또한) 김영한 개발자님이 강의를 들으며 테스트 코드를 작성했고, 이를 잘 써먹었기 때문이다. TDD는 객체지향적 개발을 하는 것과 관계 없이 유용한 경우가 많다. 적절한 데이터를 삽입하고 적절하게 롤백만 해준다면 통합 테스트로 사용하더라도 개발을 편리하게 만들어 준다.
다만, 최근 좀 더 코드를 업그레이드 하고 싶다는 욕구가 생겼다. 객체지향과 TDD간 관계는 자주 들었고, 혼자 어설프게 테스트 코드를 짜는 수준에서 업그레이드 하고 싶었기 때문이다. 가장 유명한 책인 켄트백의 TDD를 읽으려고 하였다. 하지만 최범균 개발자님의 입문서가 있기 때문에 먼저 읽었다. 매우 잘한 선택이다. 여기서 설명한 내용을 잘 실천하다 좀 더 레벨업이 필요하다고 느낄 때, 켄트백의 책을 도전해야지.