"꾸준하게, 지속하자 "

DFS를 이용한 순열과 조합의 차이

최동훈1 — Mon, 26 Aug 2024 00:40:38 +0900

백문이 불여일타 ! 코드로써 설명한다.

DFS의 파라미터로 Start를 넣느냐 안넣는냐의 차이. (permutaion은 0부터 시작)

순열의 경우

package 이코테.DFSBFS;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Scanner;

public class 연산자끼워넣기 {
    static int[] arr;
    static ArrayList<String> calculate = new ArrayList<>();

    static ArrayList<ArrayList<String>> output = new ArrayList<ArrayList<String>>();

    static boolean[] visit;
    static int plus;
    static int minus;
    static int multiplex;
    static int divide;
    //7:37~ 8: 41
    public static void main(String[] args) {

        Scanner s = new Scanner(System.in);

        int N = s.nextInt();

         arr = new int[N];
        visit = new boolean[N];
        Arrays.fill(visit, false);

        for (int i = 0; i < N; i++) {
            arr[i]=s.nextInt();
        }
         plus=s.nextInt();
         minus=s.nextInt();
         multiplex=s.nextInt();
         divide=s.nextInt();

        for (int i = 0; i < plus; i++) {
            calculate.add("+");
        }
        for (int i = 0; i < minus; i++) {
            calculate.add("-");
        }
        for (int i = 0; i < multiplex; i++) {
            calculate.add("*");
        }
        for (int i = 0; i < divide; i++) {
            calculate.add("/");
        }

        dfs(new int[calculate.size()], calculate.size(), 0);
        int max=-(int)1e9;
        int min=(int)1e9;

        for (int i = 0; i < output.size(); i++) {

            int sum = arr[0];
            //하나의 경우의 수별 최대 최소 계산
            ArrayList<String> list = output.get(i);

            for (int j = 1; j < arr.length; j++) {
                String order = list.get(j - 1);
                if (order.equals("+")) {
                    sum+=arr[j];
                } else if (order.equals("-")) {
                    sum-=arr[j];
                } else if (order.equals("*")) {
                    sum *= arr[j];
                } else if (order.equals("/")) {
                    if (sum < 0) {
                        sum = Math.abs(sum);
                        sum=-(sum/arr[j]);
                    }
                    else {

                        sum/=arr[j];
                    }
                }
            }
            max = Math.max(sum, max);
            min = Math.min(sum, min);

        }

        System.out.println(max);
        System.out.println(min);

    }
    // 순열 개산하기
    public static void dfs(int[] now, int end, int depth){
        //0 ~ end 범위에서 now.length 개의 인덱스를 뽑아서 나열하는 경우의 수 계산
        //(calculate 리스트의 범위) depth가 증가하는 상한은 now.length 개.

        if (depth == now.length) {
            //하나의 경우의 수 씩 해당 인덱스 값에 대응하는 연산자를 삽입.
            ArrayList<String> tmp = new ArrayList<>();
            for (int index = 0; index < now.length; index++) {

                int idx = now[index];

                tmp.add(calculate.get(idx));
            }
            output.add(tmp);
            return;
        }
        for (int i = 0; i < end; i++) {
            if (!visit[i]) {
                visit[i]=true;

                //여기서 나는 뽑아야되는 범위(Calculate 리스트)의 인덱스를 저장할 것임.
                //해당 '인덱스' 값으로 now 배열 완성시 Calculate에서 다시 조회해서 최종 output에 저장.
                now[depth] = i;
                //now -> 하나의 경우의 수 를 저장하기위한 배열
                //실수 주의 !!! depth는 조합을 뽑는 배열의 인덱스임.
                dfs(now, end, depth + 1);
                visit[i]=false;
            }


        }

    }
}

조합의 경우

package 이코테.DFSBFS;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.Scanner;
import java.util.StringTokenizer;

public class 연구소 {

    public static ArrayList<Node> empty = new ArrayList<>();
    public static int N;
    public static int M;
    public static int[][] map;
    public static boolean[] visit;

    public static ArrayList<Node> virus = new ArrayList<>();
    public static ArrayList<ArrayList<Node>> combination = new ArrayList<ArrayList<Node>>();
    //6:00~
    public static void main(String[] args) throws IOException {
        Scanner s = new Scanner(System.in);

         N = s.nextInt();
         M = s.nextInt();

         map=new int[N][M];


        for (int i = 0; i < N; i++) {
            for (int j = 0; j < M; j++) {
                int input=s.nextInt();
                map[i][j]=input;
                if (input == 0) {
                    empty.add(new Node(i, j));
                    continue;
                }
                if (input == 2) {
                    virus.add(new Node(i, j));
                    continue;
                }
            }

        }
        visit = new boolean[empty.size() + 1];
        Arrays.fill(visit,false);

        int max=-(int)1e9;
        int[] now=new int[3];
        Arrays.fill(now, -1);
        combi(now,0, empty.size(),0);
//        System.out.println("조합목록");
//        for (int i = 0; i < combination.size(); i++) {
//
//            System.out.println(combination.get(i).toString());
//        }



        for (int i = 0; i < combination.size(); i++) {
            int[][] temp=new int[N][M];
            for (int c = 0; c < map.length; c++) {

                for (int k = 0; k < map[c].length; k++) {
                    temp[c][k]= map[c][k];
//                    System.out.print(temp[c][k]+" ");
                }
            }

            //한 조합별로 벽 세우기
            for (int j = 0; j < combination.get(i).size(); j++) {
                Node node = combination.get(i).get(j);

                temp[node.x][node.y]=1;
            }

            for (Node virus : virus) {

                dfs(virus.x, virus.y,temp);

            }
            max=Math.max(count(temp),max);


        }
        System.out.println(max);



    }

    public static int count(int[][] tmp) {
        int cnt=0;
        for(int i=0;i<tmp.length;i++){
            for (int j = 0; j < tmp[i].length; j++) {
                if (tmp[i][j] == 0) {
                    cnt++;
                }
            }
        }
        return cnt;
    }

    public static void dfs(int x, int y,int[][] tmp) {
        //매우 중요, 시뮬레이션 처럼, 시작 점을 "이동" 하는 것이 아님.
        //시작점은 무조건 고정이고, nx,ny룰 큐에 넣거나 재귀호출 하는 것임.
        //이유: 재귀 호출이 끝나고 return 되었을때, 처음 시작점인 x,y 값이
        //변화해 버림.


        int[] dx={-1,0,+1,0};//상 우 하 좌
        int[] dy={0,+1,0,-1};

        for (int i = 0; i < 4; i++) {
            int nx=x+dx[i];
            int ny=y+dy[i];

            if(nx<0||ny<0||nx>=N||ny>=M){
                continue;
            }
            if (tmp[nx][ny] == 0) { //빈방일 경우에만 방문.

                tmp[nx][ny]=2;

                dfs(nx,ny,tmp);
            }

        }
        return;


    }
    public static void combi(int[] now, int start, int end, int depth){
        //start ~ end 까지의 범위에서 3개를 뽑는 조합.(depth는 뽑는 조합의 인덱스임)
        if (depth == now.length) {
            //3개를 다 뽑았으면 저장 후 return,

            ArrayList<Node> temp = new ArrayList<>();
            for (int i = 0; i < now.length; i++) {
                temp.add(empty.get(now[i]));
            }
            combination.add(temp);

            return;
        }

        for (int i = start; i < end; i++) {
            if (!visit[i]) {
                visit[i]=true;
                now[depth] = i;
                combi(now,i+1,end,depth+1);
                visit[i]=false;
            }
        }
    }
    static class Node{
        int x;
        int y;
        public Node(int x,int y){
            this.x=x;
            this.y=y;
        }
        @Override
        public String toString(){
            return "( "+x+" )"+"( "+y+" )";

        }
    }
}

RefreshToken은 왜 Redis를 사용해 관리할까? (with. RTR 방식)

최동훈1 — Wed, 10 Jul 2024 21:32:38 +0900

1. “왜?”

우리는 MySQL과 같은 일반 DB를 다룰 줄 아는데 사람들은
왜 굳이 리프레시 토큰을 Redis에 저장하여 사용하는지 이유가 궁금했으며,

왜 다들 Redis를 사용해서 리프레시 토큰을 저장하는 지 궁금했습니다.

2. Redis가 뭔데?

레디스는 디스크가 아닌 메모리에 데이터를 저장하는 In-Memory 방식의 데이터베이스입니다.

2-1. In-Memory?

In-Memory 데이터베이스는 MySQL과 같은 다른 일반 DB들처럼 SSD, HDD와 같은 보조기억장치가 아닌, 프로세서가 직접 액세스할 수 있는 컴퓨터의 주 메모리인 RAM에 데이터를 저장합니다.

2-2. 디스크에 저장하는 것과 무슨차이가 있는데?

특정 프로그램을 실행하면, 아래와 같이 컴퓨터는 보조기억장치에 저장된 데이터를 RAM으로 불러와 CPU가 해당 데이터를 처리하는 과정으로 실행됩니다.

Disk-RAM-CPU 플로우

여기서 장점이 확연히 보이지 않나요?

RAM에 데이터를 저장하여 사용하게 되면 보조기억장치에서 데이터를 Load하는 비용이 절약됩니다.

때문에 인메모리 데이터베이스의 읽기 및 쓰기 연산은 기존 디스크 기반 데이터베이스보다 훨씬 빠릅니다.

하지만 보조기억장치와는 다르게 RAM은 전원이 끊어지면 데이터가 전부 지워지는 휘발성 메모리(Volatile Memory)라는 특징이 있다!

3. Redis의 특징

Key-Value의 형태의 데이터베이스이기 때문에 적은 메모리로도 데이터를 저장할 수 있으며, 작성 속도가 빠름
Key-Value 형태를 가지고 있기 때문에 키를 알고 있다면 조회 성능이 O(1)까지 나온다는 장점을 가짐
인메모리 DB 방식으로 빠르게 접근이 가능
휘발성인 In-Memory DB는 영구적으로 저장될 필요가 없는 Refresh token을 관리하기에 충분
캐시처럼 데이터 만료일을 정할 수 있음

3-1. Redis의 특징이 Refresh Token 보관에 이점이 되는 이유

이러한 Redis의 특징을 토대로 Refresh Token을 보관하는 것이 적합한 이유를 설명해보자면 아래와 같습니다.

우선 RDB와는 다르게 데이터의 만료일을 지정할 수 있습니다. 이를 TTL(Time-To-Live)이라고 하는데, 이를 토큰의 만료일과 똑같이 맞춰두어 관리하면 토큰이 만료되면 Redis에서도 토큰이 삭제되도록 하여 데이터를 효율적으로 관리할 수 있습니다.
대체로 30분~2시간 단위로 갱신하는 JWT Access Token은 새롭게 갱신하기 위해 Refresh Token이 필요합니다.
이렇게 호출의 빈도가 대체적으로 높은 Refresh Token은 RDB에 저장하는 것보다 In-Memory DB에 저장해두고 사용하는 것이 훨씬 속도가 빠르고, 토큰 ReIssue 로직의 병목현상을 방지할 수 있다습니다.
모든 기술 사용에는 트레이드 오프가 존재합니다. RDB vs In-Memory DB의 트레이드 오프는 속도와 안정성이라고 생각합니다.
In-Memory 방식은 굉장히 뛰어난 조회 속도를 얻을 수 있어 호출의 빈도가 높은 토큰 ReIssue 로직의 병목현상을 방지할 수 있습니다. 하지만 In-Memory DB는 휘발성 메모리이기 때문에 전원이 끊어지면 데이터가 전부 지워집니다.
그런데 단지 Refresh Token만을 관리하기 위해 Redis를 사용한다면 이 트레이드 오프는 손실보다 이득이 더 클 수도 있습니다. Refresh Token이 모두 삭제되었을 때 발생하는 가장 큰 사건은 모든 유저가 재로그인을 해야한다는 점인데, 웬만해선 전원이 끊어질 일이 자주 발생하지 않고 때문에 유저 경험에 그리 크리티컬하게 작용하지 않는다고 생각합니다.

4. 그럼 RefreshToken은 왜 DB에 저장해서 사용하는 건데?

우선 리프레시 토큰과 엑세스 토큰에 대해 알아보겠습니다.

엑세스 토큰: 서버에 API를 직접 요청(Access)할 때 사용
리프레시 토큰 엑세스 토큰이 만료되었을 때, 엑세스 토큰을 재발급(Refresh)할 때 사용

이 둘이 분리된 이유는 보안입니다.

토큰을 탈취당하면 다른 사람이 내 계정의 권한을 사용하여 서비스를 마음대로 사용할 위험이 있기 때문에 절대 노출되면 안됩니다.

JWT 토큰은 Stateless라는 HTTP의 특징에 의해 한번 발급되면 그 뒤로 토큰의 상태에 대해 관리할 수 없으며,
그렇다보니 회원이 토큰을 통해 요청을 보낸 건지, 해커가 토큰을 탈취해서 요청을 보낸 건지 알 수 없습니다.

때문에 유저 인증 역할을 가진 엑세스 토큰은 대체로 만료시간을 짧게 잡습니다. (보통 30분 ~ 2시간 정도로 생각하는데, 서비스에 따라 다릅니다)

이러한 엑세스 토큰이 만료되면 리프레시 토큰을 통해 새로운 엑세스 토큰을 발급받게 됩니다.

때문에 리프레시 토큰은 엑세스 토큰보다 훨씬 긴 만료시간을 가집니다. (저는 보통 1주 ~ 1개월 정도로 생각하는데, 서비스에 따라 다를 수 있습니다)

4-1. 그럼 토큰이 탈취당하면 어떻게 될까요?

엑세스 토큰만 탈취 당한다면 30분 ~ 2시간 정도만 유저의 권한을 마음대로 이용하고 그 뒤엔 사용할 수 없지만,

엑세스 토큰과 리프레쉬 토큰이 모두 탈취 당하면 최악의 경우 해커는 계속해서 엑세스 토큰을 재발급하며 유저의 권한을 악용할 수 있습니다.

4-2. 이를 방지하기 위해 우리는 Refresh Token을 DB에 저장해놓고 사용합니다.

우선 위의 말 처럼 데이터베이스(Redis)에 유저 정보와 Refresh Token을 저장하여 사용합니다.

Key: 유저 고유정보 (ex. member Entity ID)
Value: RefreshToken

그리고 이와 함께 Refresh Token Rotation(RTR) 방식으로 리프레쉬 토큰을 관리하도록 설정합니다.

RTR 방식은 RefreshToken을 DB에서 관리할 때 적용할 수 있는 방식입니다.

플로우를 살펴볼까요?

(좌) 토큰 저장 및 갱신 플로우 / (우) RefreshToken 만료 시 플로우

Access Token이 만료되어 토큰을 갱신시키는 시점에

클라이언트는 토큰 갱신을 위해 토큰 갱신 API 에 AccessToken, RefreshToken을 담아 전송합니다.

전달받은 토큰의 유효성 검사가 완료되면, AccessToken을 통해 유저 정보(member PK)를 얻고,

DB에서 유저 정보에 해당하는 Refresh Token 을 조회해옵니다.

이때 'DB에서 조회해온 Refresh Token'과 클라이언트에서 '요청에 담아 보낸 Refresh Token' 이 동일하다면 토큰을 재발급합니다.

새로 발급된 Access Token, RefreshToken은 클라이언트 측에 전송되며, 새로운 RefreshToken은 DB에 갱신됩니다.

이렇게 관리하는 경우 Refresh Token을 1회용으로 사용할 수 있습니다.

그렇다면 어떻게 RTR 방식으로 어떻게 탈취로 인한 피해를 방지할 수 있는걸까요?

탈취 플로우를 통해 살펴보겠습니다.

1. 로그인 시에 유저는 Access Token과 Refresh Token을 응답받습니다.
(이때 Redis에 Refresh Token이 MemberId(Key):RefreshToken(Value) 형태로 저장됩니다.

2. 이때 유저에게 AccessToken, Refresh Token을 전달하는 과정에서 해커가 토큰을 탈취합니다.

3. 해커는 탈취한 AccessToken을 통해 유저의 권한을 사용하던 중 토큰이 만료되었습니다.
(이때 당연히 같은 토큰을 사용하는 유저도 만료가 됩니다.)

이때 유저가 먼저 토큰을 갱신하는 경우(4-1)와 해커가 먼저 토큰을 갱신하는 경우(4-2) 로 두 가지 상황이 있을 수 있습니다.

4-1. 이때 유저가 먼저 토큰을 갱신하는 경우, DB의 RefreshToken도 갱신되며
이후에 해커가 토큰 갱신을 요청했을 때 DB에 저장된 RefreshToken과 해커가 갱신을 위해 요청에 담아보낸 RefreshToken이 달라서 토큰 갱신에 실패합니다.

4-2. 해커가 먼저 토큰을 갱신하는 경우, DB의 RefreshToken도 갱신되며
이후에 유저가 토큰 갱신을 요청했을 때 DB에 저장된 RefreshToken과 유저가 갱신을 위해 요청에 담아보낸 RefreshToken이 달라서 토큰 갱신에 실패합니다.
그럼 유저는 다시 로그인해야 하며, 재로그인 시에 DB의 RefreshToken도 갱신되어 공격자가 가진 RefreshToken과 DB의 RefreshToken의 상태가 달라집니다.
떄문에 해커는 다음 토큰 갱신에서 실패하게 되며 유저의 권한을 악용할 수 없게됩니다.

이렇듯 RTR 방식으로 RefreshToken을 관리하게 되면

해커가 Refresh Token을 탈취해도, 실제 회원의 Access Token이 만료되어 토큰을 갱신하는 순간 Redis의 Refresh Token이 변경되어 해커가 탈취한 이전의 Refresh Token은 만료되어 해커는 더이상 토큰을 재발급 받을 수 없습니다.

물론 실제 회원이 토큰 탈취 이후, 한동안 로그인을 하지 않게 되면 그 동안은 해커가 계속해서 회원의 권한을 악용할 수 있습니다.때문에 HTTPS 설정이나 httpOnly, Secure 설정을 한 쿠키로 JWT 토큰을 발급하는 등의 방법으로
통신 과정의 안전성을 고려해야 하며, 토큰 탈취 가능성을 낮추기 위해 노력해야합니다.

5. Redis도 @Transactional로 트랜잭션 설정이 가능한가요?

Spring Data Redis의 공식 문서를 살펴본 결과

Redis는 트랜잭션을 RedisConfig의 추가적인 설정을 통해 @Transactional로 JPA와 하나의 트랜잭션으로 묶어 사용이 가능하다는 점을 알게 되었습니다.

template.opsForValue().set("thing1", "thing2");

template.opsForValue().get("thing1");

하지만 JPA와 같이 영속성 컨텍스트의 1차 캐시와 같은 기능을 지원하지 않기 때문에 문제가 발생할 수 있습니다.

예를 들어 위와 같은 상황에서는 thing1이 set() 메서드로 Redis에 Insert된 후 트랜잭션이 EXEC(commit) 되지 않았기 때문에

template.opsForValue().get("thing1"); 의 결과가 null이 됩니다.

JPA는 DB에 flush 되지 않아도 1차 캐시에 정보가 담겨서,
조회 시에 1차 캐시의 정보를 가져올 수 있지만 Redis는 1차 캐시라는 것이 존재하지 않아서
DB에 커밋되기 전에는 하나의 트랜잭션 내에서 발생한 변경을 조회해올 수 없습니다.

자세한 내용은 아래 공식문서에서 참고하실 수 있습니다.

https://docs.spring.io/spring-data/redis/reference/redis/transactions.html

글을 마치며

개발을 하다보며 느낀 것은 항상 100% 좋은 기술이나 방법은 없다는 점입니다. 제가 말씀드린 부분 이외에도 여러분들이 아쉽다고 느끼신 부분들이 있다면 꼭 추가해서 더욱 개선된 프로그램을 만들어가는 개발자로 성장하실 수 있으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다!

reference

https://puleugo.tistory.com/154

https://kth990303.tistory.com/431

☄️쿠석쿠석 서비스를 출시하며, feat. 성능 개선

최동훈1 — Thu, 25 Apr 2024 01:03:55 +0900

쿠석쿠석 서비스란 ?

제가 작년부터 기획하였던 건대의 장소 공유 서비스 입니다 !! 그 전까지 개발자로만 프로젝트를 참여해보았지만, 순수하게 사람들의 문제점을 해결하고자, 아이디어를 기획하고, 팀을 셋업하고, 회의를 주관하며 팀 을 이끌어본 경험은 처음이었기에 저 자신이 자랑스러웠습니다(많이컷다 최동훈..ㅎㅎㅎ) 제가 만들고자 했던 서비스라서 저에게 있어서 자식과 같은 서비스 입니다 !! ㅎㅎ.. 부족한 팀장이였지만, 다들 잘 따라와줘서 세상에 나올수 있었던 거 같습니다 !! ㅎㅎ 약 3개월동안 제가 과거에 프로젝트들의 경험을 발판삼아서, 최대한 "애자일 스러운" 팀 문화를 만들려고 노력했던거 같습니다.. ㅎㅎㅎ 매주 스크럼를 진행하며, 각 주차별 스프린트 회고를 진행하였고, 각 직군과 디자이너 분의 의사결정을 최대한 존중하며, 개발을 해 나갔던거 같습니다 !! ㅎㅎ 다시한번 끝까지 잘 따라와준 프론트 정현님, 디자이너 희수님, 백엔드 해리님께 감사합니다 ㅎㅎ

베포 도메인 : 쿠석쿠석 (kusukmap.com)

깃허브 주소 : KONKUK-MAP-Service (github.com)

그간의 기록들

쿠석쿠석 카드뉴스

출시후 사용자들의 반응

우선 지난주 학내 커뮤니티 에브리타임에 첫 출시후 반응이 좋았습니다.. ㅎㅎㅎ 그런데 사용자분들이 우리의 핵심 기능인 "사진" 과 관련되어서 속도가 느리다 라는 피드백이 있어서 해당 응답속도를 개선해 보았습니다.
https://everytime.kr/426789/v/339376642

쿠석쿠석 출시후 건대 학우들의 반응 !! 너무 감사합니다 ㅠㅠ

속도개선까지의 아이디어

저의 가장 큰 주안점은 분산된 서버 환경에서의 이미지 파일 제공 이였습니다. ! 최근 정보처리기사 실기 공부를하고 있었는데, 전세계적으로 분산되어서 파일을 저장하고, 해당 지역별로 가장 가까운 서버에서 파일을 제공 받게 한다면, 해당 이미지의 응답속도가 개선되지 않을까 ? 라는 너무 막연한 착안점을 얻었습니다.
그다음 구글링과 스택 오버플로우 검색을 해 보았습니다.

CDN 을 이용한 성능개선

다행히도, CDN 이라는 키워드를 찾을수 있었고, CDN 을 이용한 캐싱을 한다면 응답속도를 조금 더 최적화 할수 있지 않을까라는 가설을 세웠습니다.
CDN 에 대해 간략해 설명하자면,

CDN (콘텐츠 전송 네트워크, content delivery network) 간단히 말하면 지리적으로 분산된 여러 개의 서버로 사용자에게 웹 콘텐츠를 효율적으로 제공할 수 있는 서버의 분산 네트워크입니다.

좀 더 자세히 설명하자면 사용자의 물리적 위치와 가까운 엣지(Edge) 서버가 있고, 이는 파일 복사본을 임시로 저장하는 프로세스인 캐싱을 사용합니다. 그렇게 캐시된 웹 콘텐츠를 전송함으로써 전송 속도를 높이게 되고, 사용자는 콘텐츠가 로딩될 때까지 기다릴 필요가 없게 되는 것입니다.

Cloud Front 를 이용한 CDN 서버 생성

우선 AWS CloudFront 를 생성하고, 현재 쿠석쿠석에서 보유하고 있는 이미지 파일 버컷을 등록해 주었습니다.

또한 Dto에서 프론트로 응답해주는 코드에 기존 S3의 url이 아니라 CloudFront의 Url이 반환되도록 문자열 처리를 해주었습니다.

기존 반환 url : https://kusuk-image-bucket.s3.ap-northeast-2.amazonaws.com/konkuk/5b241b6f-8a31-45e9-9453-4fade5107e52.jpg

변경 후url : https://drooj3d6yc2tf.cloudfront.net/konkuk/5b241b6f-8a31-45e9-9453-4fade5107e52.jpg

CDN 적용전 반응속도 비교

현재 반응속도 ( 62ms ) (고화질 사진 4.2MB 기준)

성능 개선후 반응속도 (46.77% 개선)

그런데 CDN 을 CLOUDFLONT를 이용하여 S3 버킷을 프록시 서버로 만든뒤에, 실험을 해보니 실제로도 같은사진( 고화질 4.2MB ) 기준 46.77 % 정도 의성능 개선이 이루어 졌습니다 !! 62ms -> 33ms

감격스러운 Hit from cloudfront

실제로 해당 속도 개선이 네트워크 상황에 따른 우연인지 확인하기 위해 HTTP 응답 헤더 값을 확인해 보니 해당 S3에 저장된 이미지 파일이 CDN 서버를 통해 캐싱되어서 Cache HIT 라는 단어를 발견할 수 있었습니다 !!!!

아래의 응답해더에 보면 현대 대한민국에서 가장 가까운 서버에서 캐싱되어있던 파일이 Hit 되어서 빠르게 전송된 것을 확인할수 있었습니다 !!!

결국 내 가설이 맞았습니다 ㅠㅠㅠ !! ㅎㅎㅎㅎ 실제로 Cache HIT from cloudfront라는 단어를 보니 신기하고 뿌듯하군요...
사용자들이 준 피드백 하나하나가 너무 고마웠고, 앞으로도 지속적으로 성능 개선해 나가야겠습니다.. ㅎㅎㅎㅎ

플리보따리 서비스를 개발하며 -2024-04-04

최동훈1 — Sat, 23 Mar 2024 20:03:25 +0900

플리보따리 란 ?

도메인 : www.plypockets.com
Git hub : 플리보따리 (github.com)

안녕하세요 구독자 여러분 !!
제가 역대 한 프로젝트중 가장 애정을 가지고 진행했던 서비스에 대해서 소개해 드리겠습니다 !! ☺️
플리보따리 서비스는 선물과 함께 노래를 전송하는 익명 편지 서비스 입니다 !

플리보따리 모바일 화면

이화여대 디자인 동아리 “UXO” 와 협업하여 만들었어요 !!

저도 전문 디자이너분들과 첫 협업 경험이어서 정말 많이 배웠고, 저랑 전혀 상관없는 직군들과 소통하는 법을 배운거 같았습니다!!
제가 이 프로젝트를 진행하며 많이 배웠고 신경쓰고자 했던 부분은 바로

테스트코드 와 클린코드

였어요 !!

이번 프로젝트에서 반복문 대신 람다와 스트림을 활용한 자바8 부터 추가된 함수형 언어의 특징들을 적극적으로 이용해서 가독성 을 높이고 서로의 코드를 알기 쉽게 만든거 같습니당 !!

또 이번 프로젝트에서 예외처리의 중요성을 다시금 느끼며, 커스텀 예외처리와 handler 기능을 각 Api 마다 모두 적용해보며, 예외 상황에 맞는 status code 반환으로 프론트엔드 분들과 원할하게 협업을 이루어지게 하였습니당 ..!

또 Enum 타입으로 관리해서 실 사용시 전혀 무결성을 최대한 지키도록 구현 하였습니다 !! ㅎㅎ

@Getter
@AllArgsConstructor
public enum HttpExceptionCode {
    UNEXPECTED_EXCEPTION(HttpStatus.INTERNAL_SERVER_ERROR,  "예상치 못한 오류가 발생했습니다."),
    INVALID_ARGUMENT(HttpStatus.BAD_REQUEST,  "올바르지 않은 값이 전달되었습니다."),
    REQUEST_NOT_FOUND(HttpStatus.NOT_FOUND, "요청을 찾을 수 없습니다."),
    INTERNAL_SERVER_EXCEPTION(
            HttpStatus.INTERNAL_SERVER_ERROR, "서버 내부에서 오류가 발생했습니다."),
    PLAYLISTPACK_NOT_FOUND(HttpStatus.NOT_FOUND, "유저의 플리보따리를 찾을 수 없습니다."),
    CONTENT_NOT_FOUND(HttpStatus.NOT_FOUND, "요청한 컨텐츠를 찾을 수 없습니다."),
    USER_NOT_FOUND(HttpStatus.NOT_FOUND, "요청한 사용자를 찾을 수 없습니다."),
    USER_ALREADY_VOTED(HttpStatus.BAD_REQUEST, "요청한 사용자는 이미 투표에 참여하였습니다."),

    SPOTIFYSONG_NOT_FOUND(HttpStatus.NOT_FOUND, "해당 ID의 노래가 존재하지 않습니다.");

    private final HttpStatus httpStatus;
    private final String message;

}

현재도 운영중이라 실제 유저가 있으니, 고객들이 주는 피드백을 바탕으로 성능개선 경험도 쌓게 되었어요 !! ㅎㅎ

우선 제가 맡은 부분을 소개해 드리자면 ,

맡은 부분

회원 도메인

회원가입과 로그인

음악 도메인

노래검색, 노래 미리듣기, 노래 실시간 차트

인프라

GithubAction, AWS CodeDeploy, AWS S3 를 이용한 CI/CD
배포관련 이슈

였어요 !! ㅎㅎ

특히 제가 프로젝트를 진행할 당시 처음으로 CI/CD 를 구축해 보았어요 !! ️

그런데 원래는 ㅠ
젠킨스와 도커 조합으로 하고 있었지만, AWS 프리티어 에서 젠킨스가 너무 느리게 작동해서 도저히 쓸수 없는 지경이 되더라구요 ㅠㅠㅠ
그래서 결국 깃허브 액션을 이용했습니다 ㅠㅠㅠ

도커와 도커컴포즈 쿠버네티스는 이후 진행한 직짱건강 프로젝트에서 구축 해 보았어요 !! ㅎㅎㅎ 다음의 Episode 를 기대해 주세요 !! ☺️

또한 유저 데이터를 보고 음악 검색 페이지 에서 가장 많은 시간을 소비한다는 데이터를 보고
음악 검색 api 속도를 1.1초에서 0.4초로 70.44% 개선하였어요 !!
제 코드로 인해 여러 사용자들의 시간이 단축되었다는 사실이 너무 뿌듯했답니다 !!

과정 : ♻️ [refactor] : spotify API 성능 개선

특히 중간에 크게 기획의도를 변경해야 할 일이 생겼는데, 저번 2023 인프콘에서 들었던, “계획에 대응하기 보단 변화에 대응하길” 이라는 애자일방법론이 떠올랐던 순간이였습니다 ㅎㅎ

성과

무려 월간활성유저수 MAU 764 규모의 서비스로 성장하였어요!!
제가 만든 코드가 수백명이 사용하다니.. 진짜 테스트코드와 QA의 중요성을 느꼈습니다 ㅠㅠ

성과 MAU764명 MPV 42000달성

GoogleAnalatics4 MAU 분석

구글 애널리틱스를 이용한 유저 데이터 분석

DAU 분석

특히 뷰저블 이라는 유저 데이터 분석 툴을 처음 활용해 보았는데, 뭔가 GA4보다도 사용자 친화적 ? 으로 만들어진거 같아서 사용자의 데이터를 수집하기 좋았어요 ㅎㅎ

뷰저블 사용자 데이터

또 실제 유저가 있으니, 고객들이 주는 피드백을 바탕으로 성능개선 경험도 쌓게 되었어요 !! ㅎㅎ

회고

개발이 모두 완료되고, 함께 개발하였던 백엔드 개발자 ‘안나’ 님과 주 2회씩 계속 저희 코드에 대한 코드 리뷰를 하는 시간을 가졌어요. 정말 뜻깊었던 순간이였고, 서로 “왜? “ 를 질문하며 코드를 외울 정도로 서로의 코드에 대한 질문을 하고 답을 구하는 과정을 거쳤던거 같아요 !! ㅎㅎ

겸손하신 안나님 !

이때 경험이 서로 개발자로 성장하는데 큰 성장을 할수 있었던거 같아서 안나님께 커피를 선물해 드렸답니다!!

마무리

이번 프로젝트로 쌓은 실력이 제가 혼자 2년간 스프링을 공부하며 쌓았던 실력보다 훨씬 더 성장한거 같아요..! 이번 프로젝트를 계기로, 타 프로젝트에서 테크리드도 해보았어요!! 이건 추후에 다시 포스팅 할게요 ㅎㅎㅎ

제플리보따리에들어있는선물

저의 플리보따리 랍니다 !! ㅎㅎ

또 저에게 노래와 편지를 보내고 싶다면, www.plypockets.com/최동훈 으로 선물을 보내주세요 ! ㅎㅎ 익명(닉네임 설정이 가능하지만) 이라서 평소에 못했던 말들도 해주셔도 됩니당 ㅎㅎ

[mysql] : java.sql.sqlexception: access denied for user 'ubuntu'@'172.31.35.55' (using password: yes) 오류 해결기

최동훈1 — Thu, 22 Feb 2024 03:51:10 +0900

너무 힘들었다. 도커로 cicd 구축할떄부터 마주했던 애러였다. 도커는결국 RDS로 못쓰고, EC2 내에 mysql을 설치해서 EC2내부 mysql 주소 와 비밀번호, user: root 로 접속하니 잘 되었다.

그런데 나는 RDS를 사용하고 싶었다. 플리보따리 에서 cicd 구축할때는 해당 오류가 나오지 않았는데 왜이런지 모르겠다.

해당 오류를 해결한다고 장장 20시간이 넘게 걸린거 같다.

너무 힘들었지만 끝까지 포기하지않고 온갖 자료,블로그를 100개는 본거 같다.

드디어 해냈다.

애러코드

해당 오류는 EC2에 CodeDeoploy로 인해서 jar 파일이 실행된 뒤, 스프링 실행로그를 확인해서 나왔다.

애러의 실마리 : 설마하는 마음에 DB의 User를 새로 생성하니 애러 코드가 조금 바뀐걸 알수 있었다.

to data base 'kusuk'으로 바뀐 모습

그로 인해서 생성한 USer에 DB 스키마에 대한 권한을 부여하면 되겠다는 생각이 들었다. 결국 해당 방법으로 성공했다.

결론은 Mysql의 사용자(User)를 추가해주고, 해당 사용자에게 권한을 부여하면 된다.

Datagrip에서 접속할려는 DB에 사용자를 추가하는 모습

단, 모든 권하을 추가하면 안된다. 이유를 모르겠지만, 모든 권한을 부여하려는 명령어

GRANT ALL PRIVILEGES ON *.* TO 'ubuntu'@'172.31.35.55' IDENTIFIED BY 'vdongv1620' WITH GRANT OPTION;

을 사용하니 또 AccessDenied 가 떴다.

그래서 일단 User를 생성한뒤에, 권한을 수정하는 방식으로 해야한다.

여기 클릭한다음에 권한설정

여기를 클릭한 다음에 권한을 +버튼을 눌러서 추가한 다음에, Create,Delete,Insert,Select ,Alter 권한을 추가해주면 된다.

권한추가

이렇게 권한을 추가하면 EC2 내에서 RDS 가 연결되어있는 정보가 application.yml에 존재 하더라도 AccessDenied 오류가 나지 않고, 해당 정보로 그대로 RDS에 접속하여 스프링이 실행된다.

진짜 중간에 포기하고 싶었지만, 눈알빠져라 봤던거 같다. 이번경험을 통해 어떤 애러가 와도 해결할수 있겠다는 자신감을 얻었다.

static 필드에 @Autowired(의존성 주입) 사용하기 (2024-02-09)

최동훈1 — Fri, 9 Feb 2024 01:15:58 +0900

겉으로 보기에는 이상이 없는 코드였는데 (물론 이건 내가 실력이 없고 무지했기에 아무런 이상이 없는 코드처럼 보였던 것이다.) NullPointerException이 뜨며 에러가 뜨는 상황이 발생했다.

그래서 디버그 모드로 들어가 하나씩 살펴보던 중 이상한 부분을 발견했다.

바로 @Autowired를 사용한 service 혹은 dao가 null을 저장하고 있었다.

null을 저장하고 있던 필드는 static으로 선언된 정적 필드였는데, 이 상황에서 내가 생각했던 것은 정적 필드는 @Autowired를 사용하지 못한다는 생각이었다.

찾아보니 역시나 정적 필드는 @Autowired를 사용할 수 없었고, 이 부분을 모두 바꾸려면 일정을 맞추지 못할 것 같기에 static 필드에 @Autowired를 사용하는 방법을 찾아야 했다.

우선 static 필드에 @Autowired를 사용하지 못하는 이유는 정적 필드가 클래스 로더에 의해 인스턴스화 될 때 아직 Spring Context는 로드되지 않았기 때문에 Spring 프레임워크에 의해 관리되는 @Autowired가 동작하지 않는 것이었다.

이 방법을 해결하기 위한 방법은 두 가지가 있었다.

1. @PostConstruct 사용하기

@Autowired
private FooObject nonStaticObj;

private static FooObject staticObj;

@PostConstruct
private void initStatic() {
  staticObj = this.nonStaticObj;
}

위 코드와 같이 @PostConsturct 어노테이션을 사용해주면 된다.

나는 Java와 Spring에 대한 지식이 그렇게 깊지 않기 때문에 @PostConstruct의 기능이 무엇인지 알지 못했었고, 일반적인 생성자와 같은 기능을 하는 줄 알았다.

하지만 찾아보니 @PostConstruct는 Spring에 의존적이지 않은 Java의 기능으로, 의존성 주입이 끝난 이후의 작업이 필요할 경우 @PostConsturct를 사용해야 한다고 한다.

지금까지 그런 상황을 보지 않아 몰랐었는데 생성자가 동작하는 시점에는 의존성 주입이 되지 않은 상태라고 한다.

또한, @PostConstruct가 적용된 메서드는 Bean LifeCycle에서 한 번만 수행되는 것이 보장되므로 생성자의 호출이 여러 번 발생하는 것을 원하지 않을 경우 사용하기 유용한 것 같다.

다만, 나는 Java 8 환경에서 작업을 했기 때문에 상관이 없었지만 @PostConstruct는 Java 9부터 Deprecated 되었다고 한다.

Java 9 이상의 환경에서는 InitializingBean의 afterPropertiesSet()을 구현하여 사용하면 될 것 같다.

class TestObject implements InitializingBean {
  @Override
  public void afterPropertiesSet() {
    ...
  }
}

실행 순서는 @PostConstruct가 우선 실행되고 afterPropertiesSet()이 실행된다고 하니 알아두면 좋을 것 같다.

2. @Autowired 생성자 사용하기

@PostConsturct 말고 @Autowired 생성자를 사용해서도 정적 필드에 의존성을 주입시킬 수 있다.

@Component
public class TestObject {
  private static FooObject fooObj;
  
  @Autowired
  private TestObject(FooObject fooObj) {
    this.fooObj = fooObj;
  }
  
  // 혹은 @Autowired setter를 이용할 수도 있다.
  @Autowired
  public void setFooObj(FooObject fooObj) {
    this.fooObj = fooObj;
  } 
}

나는 1번의 방법으로 사용하였지만 위와 같은 코드로 사용하여도 static 필드에 의존성 주입을 사용할 수 있다고 한다.

물론 나는 기존 코드를 수정해야 하는 상황이었고, 전체적으로 수정하기에는 일정이 촉박하여 이렇게 static 필드에 의존성 주입을 사용하는 방법을 찾아 해결하였지만, 찾아보니 Spring의 제어를 벗어난 방식이기 때문에 가급적 사용을 자제하는 것이 좋다고 한다.

추신;

앞의 포스트에도 좋은 의존주입 방식은 생성자주입방식이라고 한다. 특히 @Lombok의 RequiredArgsConstuctor과 연계되서 스프링에서도 추천한다고 한다.

생성자 주입 방식으로 불변성을 보장하자

@Value애너테이션과 스프링 빈 생명주기 오류(2024-02-05)

최동훈1 — Mon, 5 Feb 2024 19:34:28 +0900

Issue

플리보따리 서비스에서 SpotifyApi관련 유틸을 만들고있던 과정에 발생한 일이다.

SpotifyConfig 클래스를 리팩토링 하고있었다.

간단히 설명하자면,

SpotifyApi를 생성할려면 개발자 페이지에서 발급받은 클라이언트 키와 비밀번호를 가지고 있어야 한다.
클래스는 하나의 역할을 가진다는 클린코드 철학으로 나는 SpotifyApi 관련 기능들을 SpotifyConfig 내에 맡겼다.

본론으로 들어가서

아래 코드을 보면

import javax.annotation.PostConstruct;

@Component
@Slf4j
public class SpotifyConfig {

    @Value("${spotify.registration.client-id}")
    private String CLIENT_ID;

    @Value("${spotify.registration.client-secret}")
    private String CLIENT_SECRET;

    private SpotifyApi spotifyApi;

    private static String accessToken;
    private static Instant accessTokenExpiration;
    
    private SpotifyApi spotifyApi 
    = new SpotifyApi.Builder().setClientId(CLIENT\_ID).setClientSecret(CLIENT\_SECRET).build();
//추가 메서드 생략
}

나는 문제없이 동작할거라 예상했었지만 NPE가 발생하는것이였다.

생각해보니

@Value의 필드 주입시점을 잘 모르고 있었다.
@Value 어노테이션이 필드에 붙었다면
의존관계 주입 시점에 동작한다.

추측하건데 @Component 가 붙은 SpotifyConfig 의 생성자 호출 시점은 스프링의 빈이 생성되는 시점일것이다.

참고로 스프링 빈의 생명주기는

스프링 컨테이너 생성
스프링 빈의 생성 -> 스프링의 모든 빈의 필드값 초기화(생성자 이용)
의존관계 주입-> 이때 @Value 값 주입
초기화 콜백
사용
소멸전 콜백
스프링 종료

즉, 2번의 빈의 생성시점에 SpotifyConfig 생성자가 호출되고 key 값은 null 이며,
2번이 지나간 후에야 key 값에 환경변수가 초기화된다.

그러므로 SpotifyConfig(빈객체)의 필드인

private SpotifyApi spotifyApi 
    = new SpotifyApi.Builder().setClientId(CLIENT\_ID).setClientSecret(CLIENT\_SECRET).build();

는 null 이며 NPE 가 발생하는것이다.

Solution

자 빈의 생명주기로 인해 null 이 들어간다는걸 알았다.

해결법은 바로 코드로 알아보자

해결방법 1.

@Component
@Slf4j
public class SpotifyConfig {

    private String CLIENT_ID;

    private String CLIENT_SECRET;

    private SpotifyApi spotifyApi;

    private static String accessToken;
    private static Instant accessTokenExpiration;

    public SpotifyConfig( @Value("${spotify.registration.client-id}") String id
    , @Value("${spotify.registration.client-secret}") String password)
    
    {
       this.CLIENT_ID=id;
       this.CLIENT_SECRET=password;
       this.spotifyApi 
    = new SpotifyApi.Builder().setClientId(CLIENT\_ID).setClientSecret(CLIENT\_SECRET).build();
    }
    
    }

위의 코드로 리팩토링을 하였다.

자 그럼 위의 코드를 보면 생성자 매개변수에 @Value 어노테이션을 넣었다.

결론적으로

Spring 이 빈 객체를 생성할 때 먼저 객체 생성에 사용할 생성자를 찾는다.
인수가 필요한 생성자가 발견되면 Spring은 컨테이너에서 해당 인수를 찾아 객체를 생성하기전에 주입한다.
생성자 매개변수 @Value 어노테이션이 달린 경우 Spring은 객체를 생성하기 전에 속성 파일에 지정된 값을 주입한다.

해서 빈생성시에 @Value 어노테이션의 값을 환경변수 값으로 초기화 할수있다.

정리하자면

@Value 필드 주입의 경우는 스프링 빈이 생성자로 빈 생성 후(2.과정) 의존관계 주입시(3.과정)에 필드값이 초기화가 되므로 스프링의 빈 생명주기로 인하여 null 값이 필연적으로 들어가게 된다.

스프링의 빈 생성자에서 환경변수의 값을 초기화 하려면 생성자 매개변수나 @PostConstruct 애너테이션을 사용하거나 애초에 생성자에 @Value 어노테이션을 붙이자.

End

이슈 해결 PR

: ♻️ [refactor] : spotify API 성능 개선 by ulsandonghun · Pull Request #66 · Playlist-pack/Server (github.com)

람다와 스트림만 사용하자(feat. CleanCode) 2024-01-30

최동훈1 — Tue, 30 Jan 2024 01:45:32 +0900

세뇌하자. 나는 람다와 스트림만 사용하는 프로그래머다.. ㅎ

람다식(Lambda Expression)

문법

문법은 간단합니다. 코드를 보는게 이해가 더 빠를 것이라고 생각됩니다.

public int sum(int a, int b) {
    return a + b;
}

//람다식 변환
(a, b) -> a + b;

장점

매우 깔끔하고 알아보기도 쉽다.
동작을 사용하기 위해서 클래스를 정의할 필요도 없다.
메소드의 리턴 타입도 없고, 메서드의 이름도 없다.
람다와 함께 사용할 수 있다.

매소드 이름없이 작성할 수 있기 때문에 익명 함수(Anonymous Function)라고도 불립니다. 메서드의 이름도 리턴 타입도 없지만 뭐하는 식인지는 쉽게 알 수 있다는 장점 덕분에 java8부터 추가된 것이라고 생각됩니다.

스트림(Stream) API

자바 8 이후부터 추가된 stream은 for문을 사용한 반복문이 갖는 단점들을 해결해줄 수 있다. for문이 갖는 단점으로는 쉽게 indent가 증가하고 if문 같은 분기문이 쉽게 발생한다는 점이다.

문법

stream().중개연산.단말연산

문법은 아래의 코드처럼 stream() 생성을 하고 중개 연산 결과들을 계속 반환하면서 이어가다 단말 연산을 이용해 멈춘다.

ArrayList<RacingCar> winners = new ArrayList<>();

for (RacingCar racingCar : racingCars) {
    if (racingCar.isSamePosition(racingCarOfMaxPosition)) {
        winners.add(racingCar);
    }
}
return winners;

// stream api를 활용한 식
private final List<RacingCar> racingCars = new ArrayList<>();

return racingCars.stream()
                .filter(racingCar -> racingCar.isSamePosition(racingCarOfMaxPosition))
                .collect(Collectors.toCollection(ArrayList::new));

장점

위 코드만 봐도 알듯이 코드의 길이가 확연히 줄어든다.
indent도 줄일 수 있어서 가독성이 좋다.
원본 데이터로부터 데이터를 읽기만 할 뿐, 원본 데이터 자체를 변경하지 않는다.

중개 연산 매소드

중개 연산

skip(long n) : 해당 스트림의 첫 번째 요소부터 전달된 개수만큼의 요소를 제외한 나머지 요소만으로 이루어진 새로운 스트림을 반환

단말 연산 매소드

단말 연산

anyMatch : 하나라도 조건을 만족하는 요소가 있다면 True 반환
allMatch : 모든 조건을 만족한다면 있다면 True 반환
noneMatch : 모든 조건을 만족하지 않는다면 True 반환
findFirst() : 처음으로 해당 요소를 찾았을때 Optional로 객체 반환
findAny() : 전체를 돌고 해당 요소 하나라도 찾았을때 Optional로 객체 반환
max() : 해당 스트림의 요소중 가장 큰 값을 가지는 요소를 참조하는 Optional로 객체 반환
min() : 가장 작은 값을 가지는 요소를 참조하는 Optional로 객체 반환
sum(), average() : 합, 평균값에 대하여 반환

Stream.of("3", "1", "4", "2", "5", "5") // 문자열 스트림 생성
        .map(Integer::parseInt) // 문자열 스트림을 정수형 스트림으로 변환
        .sorted() // 정렬
        .distinct() // 중복제거
        .limit(3) // 갯수를 3개로 제한
        .collect(Collectors.toList()) // 리스트로 변환 => {1, 2, 3} : 단말 연산
        .stream() // 다시 정수형 값을 갖는 스트림으로 변환
        .filter(x -> x > 1) // 1보다 큰 값만 갖도록 필터링함 {2, 3}
        .forEach(System.out::println); // 2와 3만 출력됨

Reference

https://sehun-kim.github.io/sehun/java-lambda-stream/#4

[JAVA] 예제로 배워보는 Stream & Lambda

Java 8부터 추가 된 Stream과 Lambda에 대해 알아보자.

sehun-kim.github.io

https://ahndding.tistory.com/23

[Java] Java 8 Stream이란?

Stream이란? Java8부터 지원하는 Stream은 컬렉션, 배열등에 대해 저장되어있는 요소들을 하나씩 참조하며 반복적인 처리를 가능케하는 기능이다. 이러한 Stream을 이용한다면 불필요한 for문과 그 안

ahndding.tistory.com

@NotNull VS @Column(nullable = false)

최동훈1 — Sun, 28 Jan 2024 05:57:25 +0900

한줄 결론 : 둘다 ddl 생성될때, Not null 제약조건을 걸어준다. 그러나 @Column은 실제 쿼리가 날라간 뒤에 DB에서 예외를 발생하고 @Notnull은 쿼리가 날라가기 전에 예외를 처리해준다.

오늘은 다음의 고민 때문에 글을 작성하게 되었다.

JPA에서 DDL을 자동으로 생성할 수 있는데, 이 때 not null 옵션은 어떻게 붙이나?
JPA의 엔티티 객체에 @NotNull 검증 어노테이션을 주면 어떻게 되나?
@NotNull 대신 @NotEmpty나 @NotBlank를 쓰면 어떻게 되나?
엔티티에 검증 로직을 붙이면 어떻게 작동하나?

JPA의 DDL 생성과 제약조건 매핑

JPA는 데이터베이스 스키마를 자동으로 생성하는 기능을 지원한다.

엔티티로 삼을 객체에 @Entity 어노테이션을 붙이고,

추가적으로 여러 매핑 정보를 엔티티의 필드 위에 추가하여, 자동 생성되는 DDL에 제약조건을 추가할 수 있다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "email", nullable = false)
    private String email;
}

예를 들어 위처럼 어노테이션을 통해 정보를 매핑해주면 어떨까?

create table book (
    id bigint generated by default as identity,
    isbn varchar(255) not null,
    primary key (id)
)

위처럼 자동 생성된 SQL문이 실행될 것이다.

nullable=false vs @NotNull

이 때, 내가 위 코드에 적은 내용 중 nullable = false 라는 내용이 있다.

nullable은 @Column의 속성 중 하나로, 기본값은 true이다.

값을 false로 설정해 주면, 해당 필드는 DDL 생성 시 not null이라는 조건이 붙은 채로 생성된다.

그런데, 누군가는 이런 생각을 할 수도 있겠다.

"저렇게 써주면 DB에는 null이 들어갈 수 없지만, 엔티티의 필드에 넣는 건 가능하니까 위험하지 않을까?

엔티티에 Spring Bean Validation을 써서 검증하면 어떨까?"

코드를 먼저 보자.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "email", nullable = false)
    @NotNull
    private String email;
}

어노테이션이 줄줄이 들어가니 보기가 힘들어진다!

그런데 여기서 알아낸 재미난 사실이 있다.

위 @Column에서 nullable=false를 제거해도, @NotNull이 붙어있으면 DDL 생성 시 not null로 생성된다는 것!!

이렇게만 써줬는데

이게 not null로 알아서 바뀌네?

이게 어떻게 가능할까? 다행히 이에 대해 다룬 포스팅을 찾았다.

Hibernate @NotNull vs @Column(nullable = false) | Baeldung

A quick and practical overview of @NotNull and @Column(nullable = false) in Java.

www.baeldung.com

여기에서 이에 대한 언급을 하고 있다.

How's that possible?
As it turns out, out of the box, Hibernate translates the bean validation annotations
applied to the entities into the DDL schema metadata.
(...)
However, if, for any reason, we want to disable this Hibernate feature, all we need to do is to sethibernate.validator.apply_to_ddlproperty to false.

Hibernate는 엔티티에 적용된 Bean Validation 어노테이션 역시 DDL로 변환한다는 것!

만약 이 기능을 비활성화하려면, application.properties에 다음 한 줄을 추가하면 된다.

spring.jpa.properties.hibernate.validator.apply_to_ddl=false

인용한 글에서는, 결론적으로 nullable = false 보다 @NotNull을 추천하고 있다.

@NotNull 어노테이션을 쓰면, 데이터베이스에 SQL 쿼리를 보내기 전에 예외가 발생한다.

JPA의 Repository 인터페이스가 잘못된 Entity를 저장할 때, ConstraintViolationException을 발생시킨다.

(그 때문에, @Valid나 @Validated 없이도 엔티티를 자연스럽게 검증할 수 있다)

물론 값이 검증에 맞지 않아도 객체를 생성하는 것은 가능했다.

또한, Bean Validation의 트리거가 EntityManager가 Flush된 이후이므로,

원하는 타이밍에 맞지 않아 의도치 않은 오류를 맞을 수도 있다.

그러나 nullable=false 로 @Column 어노테이션에 속성을 붙이면,

null을 넣은 엔티티를 생성하면 생성이 된 뒤 Repository에 전달되고,

이 값이 DB에 넘어간 뒤에 예외가 발생해 위험한 오류를 맞을 수 있다.

이렇게 둘의 장단점을 비교해 보았을 때,

@NotNull을 써서 DB와 서버 모두의 안정성을 챙기는 것이 좋겠다고 생각했다.

다른 Validation은?

그런데, 여기서 하나 궁금한 게 생겼다.

Spring Bean Validation에서는 @NotNull 외에도, 이와 비슷한 어노테이션을 제공한다.

@NotNull : null이 들어갈 경우 예외를 발생시킨다.
@NotEmpty : 문자열에 null이나 ""가 들어가면 예외를 발생시킨다. NotNull의 문자열 버전 상위호환.
@NotBlank : 문자열에 null, "", " "가 들어가면 예외를 발생시킨다. NotEmpty의 상위호환.

위의 @NotEmpty와 @NotBlank는, 문자열에만 적용할 수 있는 검증 어노테이션이다.

내가 단순하게 생각했을 때에는, 이 둘도 null을 금지하니까 not null 옵션을 자동으로 붙여주겠지? 라고 생각했다.

종류별로 하나씩 써봤다.

name과 content는 not null 옵션이 들어가지 않았다!!

그런데 당황스러운 상황 발생. 저 둘은 not null을 붙여주지 않는다!!

왜일까 찾아본 결과 여러 가지 정보를 얻을 수 있었다.

아래는 그 사이 했던 삽질의 기록이다.

다만, 이것은 설득력이 크지 않다. 그래서 이유를 찾기 위해, hibernate validator 페이지를 확인했다.

Hibernate 공식 문서를 읽어보다

Hibernate의 공식 validator 페이지에서는 @NotEmpty를 써야하는 상황에서 다른 방법을 권하는 것을 확인했다.

The Bean Validation reference implementation. - Hibernate Validator

Express validation rules in a standardized way using annotation-based constraints and benefit from transparent integration with a wide variety of frameworks.

hibernate.org

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}

위의 코드는 공식 페이지의 메인에서 보여주는 예시 코드이다.

@NotBlank나 @NotEmpty를 통해 not null 옵션을 조절하는 대신,

@NotNull을 통해 DB에 not null 옵션을 주고 @Size를 통해 저장할 때 서버에서 추가로 검증을 하도록 한다.

왜 @NotBlank와 @NotEmpty를 지원하지 않는지 조금 이해가 되는 느낌이었다.

추측하기로는, 일관성을 위해 @NotNull에 대해서만 not null 옵션으로 번역해 주고,

그 외의 것은 번역하지 않는 것으로 보인다.

@NotEmpty와 @NotBlank는 문자열에만 적용되는 특수한 검증 어노테이션인 만큼, 이해가 가는 부분이다.

여러분들도 @Column 대신 검증 어노테이션을 쓰려고 한다면, @NotNull 외의 다른 것을 쓰지 않도록 주의!!

* 동일 문서의 ORM 관련 파트에서는 앞서 언급한 자동 변환에 대해 보다 자세히 설명하고 있다. 읽어보시길.

* 210221 내용 추가

공식 문서에서는 @NotBlank와 @NotEmpty의 경우 Hibernate metadata impact가 없도록 설정되어 있다.

그에 비해 @NotNull은 not null 옵션이 들어가도록 설정되어 있었다.

그러면, @NotEmpty와 @NotBlank는 쓰지 않는게 좋나?

무조건 그렇다고 생각하지는 않는다.

만약 JPA의 DDL 자동 생성을 사용하지 않지만, 엔티티의 값을 검증하고 싶다면

문자열에 한해서는 @NotEmpty와 @NotBlank가 더 유리하다고 생각한다.

(예 : flyway를 이용해 DB 쿼리를 관리해서 DDL 자동 생성을 쓰지 않는 경우)

테스트를 통한 검증 로직 확인

이제 테스트를 통해 직접 확인해 보려고 한다.

package com.booksdiary.domain;

import lombok.*;
import org.hibernate.validator.constraints.ISBN;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import javax.persistence.*;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Positive;
import javax.validation.constraints.Size;
import java.time.LocalDateTime;

@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@EntityListeners(AuditingEntityListener.class)
@Entity
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @CreatedDate
    private LocalDateTime createdAt;

    @ISBN
    private String isbn;

    @NotNull
    @Size(min=1)
    private String name;

    @NotBlank
    private String content;
}

먼저, Book이라는 클래스를 사용한다. (실제 프로젝트에서 쓰는 클래스에서 필드만 줄였다)

이제 테스트 코드를 만들어 준다.

package com.booksdiary.domain;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.NullAndEmptySource;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.validation.annotation.Validated;

import javax.validation.ConstraintViolationException;
import javax.validation.Valid;
import javax.validation.constraints.NotNull;
import java.time.LocalDateTime;

import static org.assertj.core.api.AssertionsForClassTypes.assertThat;
import static org.assertj.core.api.AssertionsForClassTypes.assertThatThrownBy;

@DataJpaTest
public class BookTest {
    @Autowired
    private BookRepository bookRepository;

    @DisplayName("책을 생성하여 저장하면, 올바르게 수행된다.")
    @Test
    void saveTest() {
        Book book = Book.builder()
                .isbn("978-3-16-148410-0")
                .name("카프카")
                .content("내용")
                .build();

        Book savedBook = bookRepository.save(book);
        assertThat(savedBook.getName()).isEqualTo("카프카");
        assertThat(savedBook.getIsbn()).isEqualTo("978-3-16-148410-0");
    }

    @DisplayName("예외 테스트 : 비어있거나 null인 이름이 들어오면 예외가 발생한다.")
    @NullAndEmptySource
    @ParameterizedTest
    void invalidNameTest(String invalidName) {
        Book book = Book.builder()
                .isbn("978-3-16-148410-0")
                .name(invalidName)
                .content("내용")
                .build();

        assertThatThrownBy(() -> bookRepository.save(book))
                .isInstanceOf(ConstraintViolationException.class);
    }

    @DisplayName("예외 테스트 : ISBN 넘버가 아닌 값이 들어오면 예외가 발생한다.")
    @Test
    void invalidISBNTest() {
        Book book = Book.builder()
                .isbn("12345")
                .name("카프카")
                .content("내용")
                .build();
        assertThatThrownBy(() -> bookRepository.save(book))
                .isInstanceOf(ConstraintViolationException.class);
    }
}

학습 테스트인 만큼 엄격하게 작성하지는 않았다.

javax.validation 뿐 아니라, hibernate에서 제공하는 validation 역시 사용해 보았다.

예를 들어, @ISBN은 isbn 양식에 맞지 않는 값을 Repository를 통해 저장할 때 예외를 발생시킨다!

테스트는 무난히 통과~

DTO에 검증 어노테이션을 달아서 잘못된 값이 오는 걸 막는 건 이해가 된다.

그런데 왜 엔티티에까지 이렇게 검증 로직을 달아야 하나?

내가 생각한 이유는 다음과 같다.

의도치 않게 엔티티에 잘못된 값을 넣어도, Repository에 저장할 때 예외를 발생시켜 더 큰 문제를 막을 수 있다.
@NotNull 어노테이션을 통해 @Column의 nullable을 대체할 수 있다.
다른 사람이 코드를 봤을 때, 어떤 제약 조건이 있는지 파악하기 쉽다.

물론 단점도 존재한다. 제일 큰 단점은 코드가 더러워 보인다 라는 것.

어노테이션 때문에 스프링 하기 싫다는 사람도 많으니 뭐.

처음엔 @NotNull을 달았는데 왜 DB에 제약조건이 생기지? 로 시작된 글이었다.

쓰다 보니 공부할 게 점점 늘어서 장황한 글이 되어버렸다.

참고한 글은 다음과 같다.

Spring Boot에서의 Bean Validation : 링크

Hibernate Validator 가이드 : 링크

Hibernate Validator 공식 문서 : 링크

Hibernate @NotNull vs @Column(nullable = false) : 링크

JavaBean Validation과 Hibernate Validator 그리고 Spring Boot : 링크

Validation 어디까지 해봤니?(Toast MeetUp!) : 링크

nullable = false와 @NotNull의 차이점 : 링크

잘못된 내용이 있다면 지적 부탁드립니다.

클린코드 책 리뷰및 요약(2024-01-27)

최동훈1 — Sat, 27 Jan 2024 00:24:25 +0900

이 책을 읽기전, 혹은 클린코드에 대한 개념을 알게되기 전에 내가썼던 코드는 쓰레기 같았다.

개발은 나혼자하는 것이 아니다.

남과 같이 하는 것이다.

아래는 내가 책을 읽으며 앞으로 코딩을 하며 지켜야 할 것들을 정리해 보았다.

1. 클린코드 핵심 요약 및 정리

[ 1. 객체의 생성에도 유의미한 이름을 사용하라 ]

객체의 생성자가 오버로딩 되는 경우 어떠한 값으로 어떻게 생성되는지 정보가 부족할 수 있다. 그러므로 이러한 경우에는 정적 팩토리 메소드를 사용하는 것이 보다 명확한 코드를 작성하게 해 줄 것이다. 하지만 구현을 드러내는 이름은 피하는 것이 좋다. (p32 참고)

// 두 번째 인자가 무엇인지 파악이 어렵다.
Product product = new Product("사과", 10000);

// 이름을 부여하여 두 번째 인자를 명확하게 파악할 수 있다.
Product product = Product.withPrice("사과", 10000);

[ 2. 함수는 하나의 역할만 해야한다. ]

함수는 지정된 이름 아래에서 한 단계 수준의 추상화 수준을 유지해야 한다. 그것이 하나의 역할 및 기능만을 하는 것이다. 또는 의미 있는 다른 함수로 추출가능한 부분이 없다면 그것 역시 하나의 역할 및 기능만을 수행하고 있는 것이다.

예를 들어 다음과 같은 Switch 문은 정말 흔히 작성하는 코드이지만, 많은 문제를 내포하고 있다. (p48 참고)

public Money calculatePay(Employee e) throws InvalidEmployeeType {
  switch(e.type) {
    case COMMISSIONED:
      return calculateCommisionedPay(e);
    case HOURLY:
      return calculateHourlyPay(e);
    case SALARIED:
      return calculateSalariedPay(e);
    default:
      throw new InvalidEmployeeType(e.type);
  }
  
}

하지만 위의 코드는 다음과 같은 문제점 목록을 가지고 있다.

함수가 너무 길다. 새로운 직원 타입이 추가되면 더 길어질 것이다.
한 가지 작업만을 수행하지 않는다. 해딩 직원이 어느 타입인지 확인하고 있다.
SRP를 위반한다. 새로운 직원 타입이 추가되어도 임금을 계산하는 함수를 변경해야 한다.
OCP를 위반한다. 새로운 직원 타입이 추가되면 새로운 임금 계산 로직을 위하 코드를 변경해야 한다.
유사한 함수가 계속 파생될 수 있다. 이러한 직원의 타입에 따른 코드는 다른 곳에 중첩될 수 있다.

이를 해결하기 위해서는 Employee를 추상클래스로 만들고, 직원 유형에 따른 하위 클래스를 선언하도록 하자. 물론 하위 객체를 생성하기 위한 switch문은 불가피하다. 하지만 그래도 유사한 함수마다 분기해주는 것을 처리해줄 수 있으며, 위의 문제점 중 상당수를 해결할 수 있을 것이다.

public abstract class Employee {
    public abstract int calculatePay();
    public abstract void deliverPay();
}

public class EmployeeFactory {

    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
        switch (r.type) {
            case COMMISSIONED:
                return new CommissionedEmployee(r);
            case HOURLY:
                return HourlyEmployee(r);
            case SALARIED:
                return SalariedEmployee(r);
            default:
                throw new InvalidEmployeeType(r.type);
        }
    }

}

[ 3. 명령과 조회를 분리하라(Command와 Query의 분리) ]

앞서 설명한대로 함수는 뭔가를 수행하거나 뭔가를 조회하거나 하나의 역할만을 해야 한다. 두 개의 역할을 동시에 하면 이상한 함수가 탄생하게 된다. 예를 들어 다음과 같이 key값이 존재하는지 확인하고, 존재하지 않으면 데이터를 추가하여 성공하면 true 실패하면 false를 반환하는 함수가 있다고 하자.

public boolean set(String attribute, String value);

if(set("username", "MangKyu")) {

}

위의 코드를 접한 사람은 이 함수가 key가 존재하는 경우 overwrite하는지 혹은 존재하지 않을 경우에만 업데이트 하는지 등 자세한 내용을 알 수 없을 것이다. 그 이유는 위의 함수가 명령과 조회를 한번에 처리하기 때문이다. 그렇기 때문에 위의 함수를 분리하여 다음와 같이 작성해주는 것이 명확하다. (p56 참고)

public boolean attributeExists(String attribute);
public boolean setAttribute(String attribute, String value);

if(attributeExists("username")) {
    setAttribute("username", "MangKyu");
}

[ 4. 오류코드 보다는 예외를 활용하자 ]

오류코드를 반환하면 그에 따른 분기가 일어나게 되고, 또 분기가 필요한 경우 중첩되기 마련이다.

public Status deletePage(Page page) {
    if(deletePage(page) == E_OK) {
        if(registry.deleteReference(page.name) == E_OK) {
            if(configKeys.deleteKey(page.name.makeKey()) == E_OK) {
                log.info("page deleted");
                return E_OK;
            } else {
                log.error("config key not deleted");
            }
        } else {
            log.error("reference not deleted");
        }
    } else {
        log.error("page not deleted");
    }
    return E_ERROR;
}

이를 해결하기 위해 각각의 함수에서 예외를 발생시켜 잡는다면 코드를 더욱 간결하게 작성할 수 있다.

public void deletePage(Page page) {
    try {
        deletePage(page);
        registry.deleteReference(page.name);
        configKeys.deleteKey(page.name.makeKey());
    } catch (Exception e) {
        log.error(e.getMessage());
    }
}

그리고 이렇게 처리하면 try-catch문이 생기게 되는데, 이 역시 분리하는 것이 코드를 이해하기 쉽게 도와줄 것이다. (p58 참고)

public void deletePage(Page page) {
    try {
        deletePageAndAllReferences(page);
    } catch (Exception e) {
        log.error(e.getMessage());
    }
}

public void deletePageAndAllReferences(Page page) throws Exception {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
}

[ 5. 여러 예외가 발생하는 경우 Wrapper 클래스로 감싸자 ]

외부 라이브러리를 이용하면 다양한 예외 클래스를 마주하게 된다. 그리고 이러한 예외들을 처리하려면 다음과 같이 상당히 번거로워 진다. (p135 참고)

ACMEPort port = new ACMEPort(12);
try {
    port.open();
} catch (DeviceResponseException e) {
    log.error(e.getMessage());
} catch (ATM1212UnlockedException e) {
    log.error(e.getMessage());
} catch (GMXError e) {
    log.error(e.getMessage());
} finally {
    ...
}

이러한 상황에서 Wrapper 클래스를 이용해 감싸면 효율적으로 예외 처리를 할 수 있다. (p136 참고)

LocalPort port = new LocalPort(12);
try {
    port.open();
} catch (PortDeviceFailure e) {
    log.error(e.getMessage());
} finally {
    ...
}

public class LocalPort {

    private ACMEPort innerPort;

    public LocalPort(int portNumber) {
        this.innerPort = new ACMEPort(portNumber);
    }

    public void open() {
        try {
            innerPort.open();
        } catch (DeviceResponseException e) {
            throw new PortDeviceFailure(e);
        } catch (ATM1212UnlockedException e) {
            throw new PortDeviceFailure(e);
        } catch (GMXError e) {
            throw new PortDeviceFailure(e);
        }
    }

}

[ 6. 테스트 코드의 작성 ]

TDD(Test-Driven Development)는 실제 코드를 짜기 전에 단위 테스트를 먼저 작성하는 기법으로, 이를 통해 유연성, 유지보수성, 재사용성을 제공받을 수 있다. TDD의 핵심 규칙 3가지는 다음과 같다. (p155 참고)

실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

실제 코드를 변경한다는 것은 잠재적인 버그가 발생할 수 있음을 내포하고 있다. 테스트 코드가 있다면 변경된 코드를 검증함으로써 이를 해결할 수 있다. 그리고 실제 코드가 변경되면 테스트 코드 역시 변경해주어야 하는데, 이러한 이유로 테스트 코드 역시 가독성있게 작성하는 것이 필요하다.

그리고 테스트 코드를 작성할 때에는 다음을 준수하는 것이 좋다.

1개의 테스트 함수에 대해 assert를 최소화하라
1개의 테스트 함수는 1가지 개념 만을 테스트하라

또한 깨끗한 테스트 코드는 First라는 5가지 규칙을 따른다.

Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
Repeatable: 어느 환경에서도 반복 가능해야 한다.
Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

[ 7. 클래스의 최소화 ]

클래스 역시 함수와 마찬가지로 간결하게 작성하는 것이 중요하다. 함수는 물리적 크기를 측정했다면 클래스는 몇개의 역할 또는 책임을 갖는지를 척도로 활용하며, 단일 책임 원칙에 따라 1가지 책임만을 가져야 한다. (p173 참고)

[ 8. 클래스의 응집도 ]

객체 지향 관련 공부를 하면 높은 응집도와 낮은 결합도라는 얘기를 듣는다. 여기서 응집도란 클래스의 메소드와 변수가 얼마나 의존하여 사용되는지를 의미한다. (p177 참고)

예를 들어 다음과 같은 Stack 클래스는 size()를 제외한 모든 함수에서 두 인스턴스 변수를 사용하므로 응집도가 아주 높다.

public class Stack {
    
    private int topOfStack=0;
    private List<Integer> elements = new LinkedList<>();
    
    public int size() {
        return topOfStack;
    }
    
    public void push(int element) {
        topOfStack++;
        elements.add(element);
    }
    
    public int pop() throws PoppedWhenEmpty{
        if(topOfStack == 0) {
            throw new PoppedWhenEmpty();
        }
        int element = elements.get(--topOfStack);
        elements.remove(topOfStack);
        return element;
    }
    
}

[ 9. 변경하기 쉬운 클래스 ]

요구사항은 수시로 변하기 때문에, 변경하기 쉬운 클래스를 만드는 것이 중요하다. 변경하기 쉬운 클래스는 기본적으로 단일 책임 원칙을 지켜야 한다. 또한 구현체 보다는 추상체에 의존하여야 한다. 그리고 결국 핵심은 다형성이다.

이와 관련된 자세한 예제를 참고하고 싶다면 p186과 p189에서 참고하도록 하자.

abstract public class SQL {
    public SQL(String table, Column[] columns)
    abstract public String generate();
}

public class CreateSQL extends SQL {
    public CreateSQL(String table, Column[] columns)
    @Override public String generate()
}

public class SelectSQL extends SQL {
    public SelectSQL(String table, Column[] columns)
    @Override public String generate()
}

[ 10. 설계 품질을 높여주는 4가지 규칙 ]

모든 테스트를 실행하라: 테스트가 쉬운 코드를 작성하다 보면 SRP를 준수하고, 더 낮은 결합도를 갖는 설계를 얻을 수 있다.
중복을 제거하라: 깔끔한 시스템을 만들기 위해 단 몇 줄이라도 중복을 제거해야 한다.
프로그래머의 의도를 표현하라: 좋은 이름, 작은 클래스와 메소드의 크기, 표준 명칭, 단위 테스트 작성 등을 통해 이를 달성할 수 있다.
클래스와 메소드의 수를 최소로 줄여라: 클래스와 메소드를 작게 유지함으로써 시스템 크기 역시 작게 유지할 수 있다.

2~4는 리팩토링 과정에 해당한다. 2~4의 작업은 모든 테스트케이스를 작성한 후에 코드와 클래스를 정리하기 때문에 안전하다. (p216 참고)

[ 11. 변경하기 쉬운 클래스 ]

예시로 작성된 클린코드(p247) 역시 바로 나온 것이 아니고, 반복적인 정리 끝에 나온 코드라고 한다. 결국 좋은 코드를 만들기 위해서는 많은 시간과 노력이 필요한 것이다. 앞으로 좋은 코드를 작성하기 위해 시간과 노력을 투자하는 것을 아끼지 말도록 하자.

[ 12. 디미터 법칙 ]

디미터의 법칙은 어떤 모듈이 호출하는 객체의 속사정을 몰라야 한다는 것이다. 그렇기에 객체는 자료를 숨기고 함수를 공개해야 한다. 만약 자료를 그대로 노출하면 내부 구조가 드러나 결합도가 높아지게 된다.

다음의 코드는 지나치게 객체의 속사정에 깊이 관여하고 있다.

final String outputDir = FileManager.getInstance().getOptions().getModule().getAbsolutePath();

위와 같은 코드는 다음과 같이 나누는 것이 좋다.

Options options = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

그리고 만약 위의 클래스들인 자료 구조라면 괜찮다. 하지만 객체라면 내부 구조를 숨겨야 하므로 한번 더 수정을 해주어야 한다.

내부 코드를 자세히 살펴보니 위의 코드로 절대 경로를 얻는 이유는 임시 파일을 생성하기 위해서다. 그렇기에 우리는 위의 코드를 다음과 같이 임시 파일을 생성하라는 메세지를 보내는 것이 좋다.

BufferedOutputStream bos = ctxt.createScartchFileStream(classFileName);

즉, 데이터가 아닌 객체를 참고할 때 여러 번의 .을 사용하는 경우, 객체에게 메세지를 보내도록 변경하자.