우리집앞마당

이전에 builder pattern 에 대한 생각을 포스팅한 적이 있다. 이번엔 무심코 많이 작성하는 ~ByParameter 에 대해 얘기해보고자 한다. 개발자가 가장 많은 시간을 보내는 것은 코드 고민, 코드 작성보다 네이밍이라는 우스갯소리가 있을 정도로 네이밍은 많은 고민이 되는 부분이다. 근데 문제는 부여할 이름 후보가 너무 많아서 고민인게 아니라 도저히 쓸 이름이 없어서 고민인게 문제다. 그러다보니 요즘엔 ~ByParameter 형태의 네이밍을 메서드에 많이 이용하는 것 같다. 특히 service layer 나 repository layer 에서 많이 사용된다. @Service public class ProductService { private ProductRepository productRepo..

처음 코틀린을 접한지 5년이 다되어가고 있다. 물론 실제 현업에서 사용한건 그 반정도 밖에 안되지만 말이다. 그동안 코틀린이라는 언어에 대한 본연의 기능과 그 외 코틀린용 라이브러리, 자바 프레임워크와 코틀린과의 궁합 등등에 대해 학습은 하면서도 테스트만큼은 계속 Junit 만을 이용해오고 있었다. mock 라이브러리인 mockito 와는 이런저런 궁합문제로 진즉에 mockk 로 넘어갔지만 Junit 과 assertion 라이브러리인 AssertJ 에 대해선 크게 불편함을 못 느꼈던게 그 이유가 아닐까 싶다. 여튼 kotest 자체는 오래전부터 알고있었으나 뒤늦게 한번 훑어보기로했다. kotest 는 크게 3개의 모듈로 구분된다. 이 모듈들에 대해 간단하게 알아보자. 1. Test Framework 테스..

이전에 이런 포스팅을 한 적이 있다. ( kotlin(+JPA) entity 에서 setter 를 막을 수 있을까 ) 결론을 암울하게 끝낸 것 같아서 몇가지 해결법을 포스팅하고자 한다. 1. 프레임워크에 의존하지 않는 domain layer @Entity @Table(name = "product") class Product( @Column(name = "product_name") var name: String, @Column(name = "product_price") var price: Long, @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "product_id") val id: Long? = null, ) { fun up..

자바 백엔드 진영에서 로그는 이미 slf4j 가 평정했다. slf4j 를 기반으로 log4j, logback, log4j2 등 구현체들이 사용되고 있는 중이다. 코틀린에서도 유사하게 사용하면 되는데 아래와 같이 로깅할 수 있다. logger.info("1+1 = {}", variable) 기존 로거에서 {} 와 같이 템플릿을 지원한건 로그 레벨에 따른 레이지 연산을 지원하기 위해서였다. 가령 예를 들어 logger.info("1+1 = " + variable) 이렇게 작성하면 메세지와 변수 variable를 더하는 연산이 무조건 실행된다. 이 무조건이라는 표현은 애플리케이션 로그 레벨이 warn 으로 설정되어 info 레벨의 메세지를 로그를 남기지않아도 되는 환경에서도 실행된다는 의미이다. 다만 첫번째 ..

spring batch 를 이용해 많은 batch job 을 만들지만 배치를 테스트하기란 쉽지않다. 하지만 배치도 분명한 하나의 애플리케이션인만큼 테스트 작성에 대한 욕구가 있었는데 그것들을 정리해보고자한다. 먼저 spring batch reference 에서 테스트 코드에 대해 가이드하고있는 부분이 있는데 가이드 문서가 불친절해 제대로 테스트를 작성하기 힘들었다. 실전 엔터프라이즈 애플리케이션에서는 해당 가이드대로 했을때 도저히 테스트를 구동할 수 없었고, 많은 삽질끝에 얻은 결론을 정리하려한다. # batch job 작성 @Configuration class SampleBatch( private val jobBuilderFactory: JobBuilderFactory, private val stepB..

요즘 자바코드를 보면 클래스를 정의할때 무조건적으로 builder pattern 을 적용하는걸 심심찮게 볼 수 있다. 회사코드에서도 그렇게 작성된 코드를 쉽게 접하기도 한다. 더욱이 롬복에서 @Builder 라는, 아주 간편하게 빌더 클래스를 만들어주는 기능을 제공해주다보니 빌더 클래스를 만드는 것에 대한 부담도 없다. @Builder class Person { private String name; private int age; } 사용하는 쪽에선 이렇게 사용한다. Person p = Person.builder() .name("LichKing") .age(34) .build(); 언제부턴가 이렇게 빌더패턴이 거의 디폴트가 되다시피 한거같은데 개인적인 추측으로는 빌더패턴이 이렇게 퍼지게된건 이펙티브 자바의..

spring framework 를 이용하여 트랜잭션을 제어할 일이 생기면 대부분 @Transactional 애노테이션을 이용할 것이다. 이 방식은 가장 간단하기도하며 spring 을 공부하는 자료들에선 대부분 선언적으로 트랜잭션을 다루는 세련된 기법이라고 소개한다. spring 을 공부할때 접하게되는 대표적 키워드들중 AOP 가 있는데, AOP 를 가장 처음으로 접하게 되는 기술이기도하다. 다만 이 방식에는 몇가지 불편한점이 있는데 1. 메서드 레벨에 AOP 가 적용되기 때문에 트랜잭션 단위도 메서드 레벨로 적용(메서드 내에서 지정 불가능) 2. self invocation 에서 트랜잭션 적용 불가 가 대표적이다. 특히 2번은 spring 을 처음 접하는 주니어 개발자라면 이 문제로 인한 삽질을 한번쯤은..

# 이슈 annotation class CustomAnnotation 위와 같이 커스텀 애노테이션을 정의한다. 애노테이션은 다양하게 활용할 수 있지만 내 의도는 프로퍼티에 사용하려는 의도라고 가정한다. class Person( name: String, ) { @CustomAnnotation val name: String = name } @Test fun findAnnotation() { val person = Person3("LichKing") val properties = person::class.memberProperties for (property in properties) { if (property.name == "name") { assertThat(property.hasAnnotation())...

spring batch 에서 JdbcPagingItemReader 를 이용해서 데이터를 조회하는 코드를 작성했다. 이후 배치 잡을 실행했는데 아래와 같은 에러 메세지와 함께 잡이 실패했다. Column 'column4' not found.; nested exception is java.sql.SQLException: Column 'column4' not found. column4 는 임의로 이름을 바꾼거고, 실제로 존재하는 컬럼명을 넣었었다. 혹시 컬럼명에 오타가 있는건가 해서 오타도 확인해보고, 실제로 쿼리를 직접 SQL 에서 실행할때는 잘 돌아가는 것까지 확인했다. JdbcPagingItemReader 를 만드는 코드도 일반적인 관례를 따랐으며, QueryProvider 를 이용했다. SqlPagin..

kotlin + jpa 를 사용할때 가장 고민되는 것중 하나는 entity 에 class 와 data class 중 어떤걸 사용하는가에 대한 선택이다. 사실 class 를 이용할때는 아무런 이슈가 없다. data class 를 사용하고 싶다는 의문?유혹? 이 들때 이런 고민을 하게 될텐데 몇가지 우려되는 부분들을 확인해보자. 1. spring guide spring guide 에서는 JPA 는 data class 가 제공하는 메서드들을 염두하고 작성되지 않았으므로 class 를 사용하라고 한다. Here we don’t use data classes with val properties because JPA is not designed to work with immutable classes or the m..