기본 생성자가 엔티티에 존재하지 않다는 내용이다. 구글링하여 찾아보니, DB와 엔티티가 매핑되려면 기본 생성자를 만들어줘야 한다는 것이다.

'왜 기본생성자를 만들어 줘야할까?' 하는 궁금증이 생겼다.

JPA에서 기본 생성자 만들어줘야 하는 이유

DB에 존재하는 데이터를 엔티티에 매핑하는 과정은 JPA에서 빈번하다. JPA는 DB 데이터를 객체 필드에 주입할 때 기본 생성자로 객체를 만들고 Reflection API를 통해 값을 매핑하게 된다.

🔘 Reflection API? 정확한 클래스 타입을 알지 못해도 그 클래스의 정보들(타입, 필드, 메서드 등)에 접근할 수 있게 해주는 API이다.

그러나 Reflection API는 생성자의 매개변수 정보를 알 수 없다. 그렇기 때문에 기본 생성자를 만들어줘야 Reflection API가 객체를 생성할 수 있고, 생성된 객체로 필드 값을 매핑할 수 있다.

기존의 개발방식

백엔드에서 DB 로직을 작성하고, 서비스 로직, 컨트롤러 로직 순으로 작성하고 나면 하나의 API가 만들어집니다.

DB -> 서비스 -> 컨트롤러 => API 완성!

위와 같이 한번에 원큐로 완성되면 정말 좋겠지만, 저같은 경우는 그렇지 않더군요.

DB -> 서비스(어라? 파라미터 뭔가 모자른데?) -> DB -> 서비스 -> 컨트롤러(파라미터 또 모자란다..) -> 서비스 ...(반복)

테스트를 도입한 개발방식

DB 테스트 작성 -> DB 로직 작성 -> 서비스 테스트 작성 -> 서비스 로직 작성 -> 컨트롤러 테스트 작성 -> 컨트롤러 로직 작성

본 로직을 작성하기 전에 테스트(단위 및 통합) 코드를 작성하는 패턴으로 개발했습니다. 테스트는 또 아래 3단계를 거치곤 합니다

1. Red: 빨간불을 뜨게 하라. 테스트 작성 전, 어떤걸 개발할 것인지 생각하는 단계
2. Green: 초록불을 뜨게하라. 어떻게 개발할 것인지 생각하고 작성하는 단계
3. Refactor: 개선하라. 작성한 코드를 개선하는 단계

테스트를 도입한 개발방식에서는 효과적인 테스트 코드를 작성하기 위해서 로직에 대해 다시한번 생각하게 됩니다. 그래서 기존의 개발방식과는 다르게 실수를 많이 줄일 수 있었죠.

테스트의 장점

테스트를 작성하는건 코드를 작성하는데에 실수를 바로잡는 역할을 하기도 합니다. 또한, 언급은 안했지만 전체적인 테스트 코드를 실행하고 나면, 혹여나 변경된 로직으로 영향을 끼친 코드가 있는지 테스트 코드로 확인할 수 있는 장점이 있습니다.

테스트의 단점

테스트를 도입한 개발방식이 기존 개발방식보다 시간적으로 더 느릴수도 있습니다. 위에서 봤던 테스트를 도입한 개발방식에서는 비즈니스 로직을 작성하기 전에 테스트를 먼저 작성하는 TDD 방식을 따랐습니다. 테스트를 추가적으로 작성해준다는 것 자체가 시간을 더 쓰게 만들수도 있는것이죠.

어떤상황에서 테스트를 추천 혹은 비추천 할까요?

추천: 프로젝트의 문서화 작성, 유지보수가 편한 프로젝트를 위함 비추천: MVP를 만들어야 하는 프로젝트, 빠른 시간안에 완료해야 하는 프로젝트

마무리

이렇게 '테스트 코드를 작성하면서 느낀점'을 간략히 작성해봤습니다. 감사합니다.

public class CommentCreateRequest {

    @NotBlank(message = "내용을 입력해주세요.")
    @Min(value= 10, message = "내용은 10자리 이상 입력해주세요.") // Not working
    private String content;

}

알아보니 @Max @Min은 숫자 필드에만 적용되는 사실을 알았다.

문자열 필드엔 @Size를 적용해야 한다.

public class CommentCreateRequest {

    @NotBlank(message = "내용을 입력해주세요.")
    @Size(min = 10, message = "내용은 10자리 이상 입력해주세요.")
//    @Size(min = 10, max = 255, message = "내용은 10자리 이상, 255자리 이하로 입력해주세요.")
    private String content;

}

@Size는 필드의 범위를 나타내는데 에도 효과적으로 보인다. 참고로 @Size는 String 외에도 Collection, Map, Array 필드를 지원한다.

Optional의 orElse

public T orElse(T other) {
    return value != null ? value : other;
}

** Optinal의 value값이 null이 아니라면 그대로 value 반환하고, 그렇지 않으면 other(값)를 반환한다.**

Optional의 orElseGet

public T orElseGet(Supplier<? extends T> supplier) {
    return value != null ? value : supplier.get();
}

Optinal value 값이 null이 아니면 value를 반환해주는건 orElse와 같다. 다만, orElseGet은 null일때 함수로 넘어가는 점이 다르다. (supplier.get)

Optional의 orElseThrow

두개가 있는걸 이제 알았다.

// 첫번째
public T orElseThrow() {
    if (value == null) {
        throw new NoSuchElementException("No value present");
    }
    return value;
}

첫번째 orElseThrow는 Optional의 value가 없다면 NoSuchElementException 예외를 발생시킨다. 값이나 함수로 넘어가지 않고 예외를 발생시키는 점이 다르다.

// 두번째
public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier) throws X {
    if (value != null) {
        return value;
    } else {
        throw exceptionSupplier.get();
    }
}

두번째 orElseThrow는 Optional의 value가 없다면 '내가 넘긴 파라미터 예외로' 예외를 발생시킨다. 이 예외는 함수로 호출한다. 함수로 넘어가되, 사용자 지정 예외(?)로 예외를 발생시킨다.

틀린 부분이 있다면 피드백 부탁드립니다!

인프런에서 주최한 인프콘2023을 가서 들었던 세션들에 대해 후기를 남기고 싶어서 글을 적게 됐다. 내가 들은 세션들은 아래와 같다.

들었던 세션들

10:00 오프닝 | 인프랩의 미래 - 교육을 넘어 라이프타임 커리어 플랫폼으로 이형주, 이동욱,홍연의 11:40 ~ 12:20 출시 3일 만에 앱스토어 2위를 달성한 사이드 프로젝트 - 김현준, 김아인 12:40 ~ 13:00 왜 내가 만든 서비스는 아무도 안쓰지? - 이동훈 14:00 ~ 14:40 어느날 고민 많은 주니어 개발자가 찾아왔다 2탄 - 김영한 15:40 ~ 16:20 스프링과 함께 더 나은 개발자 되기

!! 지금부터는 세션마다 제 개인적인 후기를 적은 것임을 알려드립니다. !!

10:00 오프닝

처음엔 인프랩 CEO 이형주 님이 나오셔서 인프랩 비전, 목표, 미래에 대해 간략히 말씀해 주셨고, 두 번째 인프랩 CTO 이동욱 님은 22/23년에 했던 것을 회고하고, 나아가 23/24년에 출시될 기능까지 미리 알려주셔서 참가자들의 감탄을 자아냈다. 마지막으로 홍연의 님은 인프콘 즐기는 방법을 간략하게 알려주셨다.

특히 이동욱 님의 발표를 더 보자면, 2022/2023년에 개편사항에서 인프런 수강자 입장의 나는, 편의성을 다시 한번 느끼며 감동하지 않을 수 없었다. 또한 2023/2024년 출시될 기능 모두 인프런, 랠릿을 사용하는 사람들에게 득이 될 것으로 보여서 기대가 된다.

11:40 ~ 12:20 출시 3일 만에 앱스토어 2위를 달성한 사이드 프로젝트 - 김현준, 김아인

이 세션은 2명의 강연자가 나와서 발표하는 자리였다. 20분은 김현준 기획자 및 마케터가 강연하셨고, 나머지 20분은 김아인 개발자(iOS와 flask서버)가 강연하셨다. (두 분 다 고3이였다) 이 앱의 이름은 skrr(스컬) 이다.

김현준 님은 기획자 및 마케터로서

1. 스컬이란 앱이 어떻게 시작 그리고 과정
2. 마케팅 방식
3. 팀장이라는 위치에서 회고

등을 말했다.

김아인 님은 개발자로서

1. 프로젝트 아키텍처에 대한 설명
2. 운영하며 생기던 여러 가지 이슈
3. 개발자다운 회고

등을 말했다.

이 사이드 프로젝트인 스컬을 만든 스컬팀의 행동력이 대단했다고 판단했다. 특히, 아키텍처를 완벽히 따지지 않고 일단 해보자는 실행력에 인상 깊이 봤다. 현재 가지고 있는 한정적인 자원으로 어떤 것을 할 수 있을까를 고민하고 행동한 실행력이었다.

12:40 ~ 13:00 왜 내가 만든 서비스는 아무도 안쓰지? - 이동훈

이번 세션도 사이드 프로젝트(이하 사.프)에 대한 발표였다. 이동훈 개발자님은 많은 사.프를 만들었고, 코로나맵을 만드신 분이었다.

개발자는 문제를 찾는 사람 이란걸 강조하셨다. 문제를 찾아야 한다는건 알고 있었는데 어떻게 찾아야 할까? 에 대한 세션이었다.

1. 내가 원하는것 말고, 상대방이 무엇이 불편해서 문제가 생기는질 관찰하라. 내가 원하는걸 사.프로 개발하면, 고객 니즈를 내 프로젝트에 끼워 맞추게 되는 문제점이 발견된다.
2. 내가 원하되, 고객의 입장이 되어보자. 고객의 입장이 되어본다면 무엇이 불편한지 접근할 수 있다.

14:00 ~ 14:40 어느날 고민 많은 주니어 개발자가 찾아왔다 2탄 - 김영한

이 세션은 김영한 지식공유자님의 발표였다. 1탄은 유튜브로 보고 2탄을 참가했다. 세션 참여자들이 정말 많았다. 그래서 더 기대되는 세션이었다.

처음엔 지식공유자로 업을 변경한 이유를 간략히 설명해 주셨다. 과거에도 교육을 해보셨던 분이라는 걸 이때 알았다. 실무중심의 개발자 강의를 만들고 싶어 하시는 야망을 느꼈다.

전체적인 내용은 꾸준히 열심히 하라는 내용이었지만, 강의 때와 같이 실무적인 예시를 많이 들어주셔서 이해가 더 잘됐다.

15:40 ~ 16:20 스프링과 함께 더 나은 개발자 되기 - 이일민(토비)

전체적인 내용은 스프링은 역사와 철학이 있고, 그렇기 때문에 '스프링을 그냥 쓰지말자' 라는 내용이였다.

컨트롤러 서비스 레포지토리 레이어를 나눠서 디비 연결하고 등등, 기계적으로 쓰지말고 좀 더 깊숙히 탐구해보자는 말과 그렇게 하면 스프링이 성장한 것 처럼 당신도 같이 성장 해 있을 것이라는 말도 해주셨다.

블로그에 대한 견해도 말씀하셨다. 블로그를 하는건 좋지만, 나만의 글로 쓰도록 하라는 점, 내 것을 만들려면 내 생각을 써야한다는 점 등 블로그를 시작하는 나에게 큰 용기가 됐다.

마지막으로 본인이 열심히 기여하여 커뮤니티가 되어보세요. 라고 말씀하신게 나에게 큰 울림이 됐다.

마무리

처음 인프콘 행사에 참여하게 됐는데, 인프런에서 강의에서만 봤던 지식공유자 님들과 커뮤니티에서 사진으로만 봤던 분들을 오프라인에서 직접 마주보니 감회가 새로웠다. 그리고 강연을 모두 듣고 난 후, 강연을 듣는 이유가 무엇일까를 다시한번 고민해 보는 시간도 됐다.

크게 두가지 라고 보았다.

1. 내가 몰랐던 부분을 강연자의 경험을 통해 들을 수 있게 되는 점
2. 내 기억 깊숙이 자리잡고 있는 앎을 다시한번 일깨워주는 점

한 가지 아쉬운 점이 네트워킹 이였는데, 혼자 행사를 가서 그런지 네트워킹이 너무 뻘쭘해서 어떻게 할지 몰라 했었다. (결국 간식만 받고 바로 집으로 왔다..) 네트워킹까지는 참여 하지 못했지만, 다음엔 꼭 참여해서 여러 사람들과 대화를 나눠보고 싶다.

우선 validation을 사용하려면 spring 프로젝트에서 build.gradle 파일의 dependencies 를 추가해줘야 한다.

implementation 'org.springframework.boot:spring-boot-starter-validation'

예시는 Controller에서 책(Book)을 추가하기 위해 Request Body에 책 이름을 받는 클래스를 만들어 주도록 하겠다.

public class BookCreateRequest {

//      어떤걸 써야할까?
//    @NotNull
//    @NotEmpty
//    @NotBlank
    private String title;
}

@NotNull

null을 허용하지 않는 validation. 단, 빈칸("", " ")을 허용 한다.

@NotEmpty

여기서는 null과 비어있는 문자열("")을 허용하지 않는 validation. 단, 공백(" ")을 허용한다.

@NotBlank

null과 빈칸("", " ") 모두를 허용하지 않는 validation.
3가지가 이해됐다면, 요구사항에 맞게 validation을 고르자.

public class BookCreateRequest {

    @NotBlank // null과 빈칸("", " ") 모두 허용하지 않기에, @NotBlank를 사용한다.
    private String title;
}

• lombok 라이브러리가 필요합니다!

기본적으로 자바는 클래스 생성 시, 기본 생성자를 통해 객체를 만들 수 있게 된다.

public class OrderMatching {

    private String title;

}

OrderMatching orderMatching = new OrderMatching(); // ok

다만, 자바의 이러한 기본적인 부분이 객체를 생성해 개발할때, 오해를 불러일으킬 수 있는 코드가 될 수 있다.

'난 title 파라미터를 받는 생성자만 사용해서 객체를 생성할꺼야' 라고 했을때를 가정해보자.

public class OrderMatching {

    private String title;

    public OrderMatching(String title) {
        this.title = title;
    }
}

OrderMatching orderMatching1 = new OrderMatching("테스트1"); // ok
OrderMatching orderMatching2 = new OrderMatching(); // 의도하지 않음

우리가 의도한 객체 생성자는 orderMatching1 이였지만, orderMatching2 방식으로 할 수 있는걸 볼 수 있다. orderMatching2 방식은 쓰지 않으니 명시적으로 막아두는게 좋을 수 있다.

public class OrderMatching {

    private String title;

    protected OrderMatching() { }

    public OrderMatching(String title) {
        this.title = title;
    }
}

OrderMatching orderMatching1 = new OrderMatching("테스트1"); // ok
OrderMatching orderMatching2 = new OrderMatching(); // 컴파일 에러

이걸 롬복 어노테이션을 통해 의미를 상단에 명시해줄 수 있다.

@NoArgsConstructor(access = AccessLevel.PROTECTED) // 추가
public class OrderMatching {

    private String title;

    // protected OrderMatching() { } // 삭제

    public OrderMatching(String title) {
        this.title = title;
    }
}

OrderMatching orderMatching1 = new OrderMatching("테스트1"); // ok
OrderMatching orderMatching2 = new OrderMatching(); // 컴파일 에러

느낀점

코드라는건 말하는 것, 글을 쓰는 것과 같다고 생각한다. 그렇기 때문에 무의식적으로 코드를 써내려가기 보다, 그 의미를 곱씹으면서 써 내려가는것이 좋겠다. 다른 사람들이 봤을때, 이 코드의 의도를 알 수 있게끔.

이상한점이 있다면 꼭 알려주세요!

시작하게 된 계기

커피를 먹고 싶을 때 자주 찾는 아담한 카페가 집 앞 3분 거리에 있다. 쿠폰 적립을 종이로 하는 카페다. 이 카페는 쿠폰 적립 종이를 가게에 보관해 주고 있다. 그래서 쿠폰이 많아짐에 따라 보관할 수 있는 '보관함'이 늘어나는 걸 확인할 수 있었다. 내가 이 부분을 해결해 줄 수 있을 것으로 보였다.

유사 서비스

비슷한 서비스가 있었다. 바로 도도 포인트 라는 서비스였다. 내가 구현하려는 애플리케이션 의도와 주요 기능[핸드폰 번호를 입력하면 쿠폰이 적립된다.]이 같고, 심지어 브랜드 마케팅 효과에 도움을 주는 기능들도 여럿 있었다. 가격은 2023년 5월 11일 기준으로 3년 약정 월 2만 원 정도 하는 서비스다. 카페 사장님에게 이 서비스를 제안 해봤지만, 가격이 부담돼 못할 것 같다고 하셨다. 그만큼 작은 카페였다.

순간적으로 이 문제를 해결한 몇 가지가 떠올랐다.

• 집에서 뒹굴던 안드로이드 샤오미 태블릿
• Typescript 학습 의지
• Next.js를 Typescript로 구현해 보고 싶다는 다짐

이후로 간단한 설계에 들어갔다.

간단한 구조 설계

• 프론트엔드 및 백엔드: Typescript 기반의 Next.js(react.js)
• 데이터베이스: Firebase Realtime Database Or Cloud Firestore
• 배포: Vercel

이 설계는 MVP(Minimum Viable Product)로 개발해서 간단히 배포하는 데에 초점을 뒀다.

이 토이프로젝트가 끝나면 얻어갈 것들

토이 프로젝트나 사이드 프로젝트는 끝나고 나면 나에게 남는 게 있어야 한다 는 이 원칙을 고수하는 편이다.

• Typescript 자바 백엔드 개발자 이지만 자바스크립트를 좋아해서 배워보고 싶었다.
• Next.js 13 버전 Next.js 12 버전의 앱은 개발을 해봤기 때문에 13버전으로 해보고 싶은 마음이 컸다.
• Firebase Realtime Database에 대해서
• 개인정보 처리 방침에 대해서
• 기타 등등

마무리

간단한 구조 설계를 만든 후, 구현 중에 중요하고 생각하거나 이슈가 있는 부분을 여기에 기록 해두려고 한다. 내가 개발 블로그를 시작하다니, 감회가 새롭다.

사실 이 프로젝트는 안 해도 되는 프로젝트다. 이유는 도도 포인트라는 서비스가 있기 때문인 점도 있고, 무엇보다 가게에서 쿠폰 종이를 보관하지 않으면 되는 문제기 때문이다.

문제를 애플리케이션 개발 없이 해결된다면, 최고의 해결책이 아닐까 라는 생각을 문득 해본다.