[개발생각] Kotlin JDSL사용을 해야 했어....

이번 프로젝트에서

jpa를 적극적으로 사용하되,

배치등에서는 mybatis를 사용하고,

어드민에서는 querydsl을 사용하는것으로 결정을 했었다.

 

api프로젝트에서는 jpa를 적극적으로 사용하여, 쿼리의 중복이나 엔티티의 관리를 철저히하는 방향으로 갔고,

배치등에서는 배치잡의 특성상 조인과 조건등이 복잡한 쿼리가 다수존재하고,

해당 조건들을 jpa로 풀어낼수가 없는 경우도 많아서, mybatis를 사용하기로 했다.

 

하지만, 지금 생각하면, 아쉬운 결정을 한것같다.

 

api쪽은 jpa를 통해서 엔티티를 관리하는 방법을 사용했기에, 몇몇 통계데이터를 jpql쿼리로 사용하는것 말고는 거의 대부분을 Repository인터페이스를 통해 구현을 했기에, 일관성을 유지하고 중복을 제거하는 효과를 보았다. 

 

하지만 배치쪽 프로젝트는 mybatis를 사용함에 따라..

결국 또 중복 쿼리나 mapper가 관리가 되지않는 케이스가 발견이 되었다.

결과가 안좋을수도있다고는 생각했지만, 개발자들이 잘 정리를 하면서 하면 되겠지 라는 안일한 생각을 했는데..

역시, 다수의 개발자들이 개발을 진행할때, 다른개발자의 코드를 보고 중복/개선을 해나가면서 하기란 어려운듯하다..

(뭐, 어렵지만 이걸 해내는 집단도 사실은 있다.. 하기나름이긴하지만;;;.. 어려운 일이긴하지..)

 

그래도, 배치쪽의 잡들이 많이 정리가 되고, 카테고리화되고, 정제된 상태로 개발이 진행되긴해서, 

엄청나게 관리가 안된것은 아니지만, 그래도 좀 아쉽긴 하다.

 

가능하다면, kotlin jdsl로 바꾸고싶은 생각이 있다.

역시 조금의 예외를 둬버리면, 그 틈을 파고드는게 개발인듯하다.

mybatis의 그 무질서함의 단점이 결국은 나타나게 됬으니 말이다..

 

아래 jpql

@Query("""
    select u
    from User u
    where u.name = :name
      and u.age >= :age
""")
fun findUsers(
    name: String,
    age: Int
): List<User>

 

아래 jdsl

fun findUsers(
    name: String,
    age: Int
): List<User> {
    return queryFactory.listQuery<User> {
        select(
            entity(User::class)
        ).from(
            entity(User::class)
        ).whereAnd(
            path(User::name).equal(name),
            path(User::age).greaterThanOrEqualTo(age)
        )
    }
}

jdsl을 사용하면, 기존 jpa entity를 그대로 사용할수있고, 빌더패턴으로 쿼리를 만들어 사용할수있다.

물론 queryDsl도 위와 비슷하게 사용이 가능하지만, QueryDsl의 단점중에 단점...

QClass 컴파일이 jdsl은 없다는게 가장큰 장점이다.

 

JpaRepository와 Jdsl을 같이 혼합하여 잘사용하면,

jpa entity를 유지하면서, 복잡한 쿼리등을 관리하는데 더욱 유용할것같다.

 

우선은 오픈하기전에 시간이 주어진다면,

api프로젝트쪽의 jqpl쿼리로 구성된 부분은 jdsl로 수정을 하는 방향을 좀 생각해봐야겠다.

배치, 어드민등의 프로젝트보다, 도메인의 관리가 더 철저해야하는 api프로젝트는 jdsl로 변경을해서,

일관성을 가져가는것이 더 좋다고 생각이 되기 때문이다.

 

예전에는 완성이 거의된 기능들을 유지/관리/개선의 명목으로 수정을 하는것이 너무 무서워했었다.

당연한것이, 잘못하면 버그가 양산되는것이고, 잘하면 현재처럼 동작하는것이니, 사실 열심히해야 본전인 작업이기 때문이다.

하지만, 요즘은 그냥 여러생각하지않고, 그냥 바로 개선/수정해버린다.

(지금 안하면, 또 언제할까?라고 생각을 한다랄까?ㅋ)

 

그 개선작업을 했냐, 안했냐에 따라, 향후 유지보수,기능추가에 막대한 영향을 끼치기 때문이다.

 

개선에 대한 두려움은 이겨내야한다.

개선하지 않은 코드들이 향후 발생시킬 버그들을 생각하면, 이겨내야한다는 말이 어떤의미인지 알수있는 날이 온다.

 

요즘은 intellij가 있어서, 대량의 개선, 코드수정등도 쉽지않아? ㅋㅋㅋ

 

My God is intelliJ