2/26(목) ERD 설계, API 명세, 프로젝트 생성, 회의록 방식

dev_joo·2026년 2월 26일

스파르타 Java 단기심화 6기 TIL

목록 보기

25/46

코드 카타

문자열에서 가운데에 있는 글자 문자열로 반환

class Solution {
    public String solution(String s) {
        // 홀수일 때: /2 후 +1 = 가운데
        // 짝수일 때: 4 -> 2,3번째 => /2 후 다음 수도
            //검증: 2 -> 2/2 = 0 (0,1번째)
        int base = s.length()/2 -1; // 인덱스 -1, 캐스팅 과정에서 자동 버림
        
        if(s.length() %2 == 0) 
            return ""+ s.charAt(base) + s.charAt(base+1);
        else 
            return ""+s.charAt(base+1);
    }
}

substring()을 사용하면, charAt() 두 번 쓸 필요 없이 계산을 직관적으로 할 수 있다.

class Solution {
    public String solution(String s) {
        int mid = s.length() / 2;
        
        if (s.length() % 2 == 0) {
            return s.substring(mid - 1, mid + 1);
        } else {
            return s.substring(mid, mid + 1);
        }
    }
}

조건문 없이도 가능:

class Solution {
    public String solution(String s) {
        int mid = s.length() / 2;
        return s.substring((s.length() - 1) / 2, mid + 1);
    }
}

프로젝트 피드백

ERD 설계

DB설계에 대해서는 이미지 저장방식등에 대해서정도만 논의하면 끝난 줄 알았는데,
여전히 고칠 부분이 많았다.

우리가 만들 배달 플랫폼 프로젝트엔 배달 관련을 생략하고 만들기 때문에, 주문 도메인에서 상태값을 DELEIVERY 값을 가져야 나중에 배달이 추가되면 주문 수락하는 동시에 완료된 주문으로 만드는 대신 배달 과정을 표시할 수 있을 줄 알았는데,

튜터님께서 피드백해주시길, 이것은 주문 도메인에 배달 도메인이 침범한 것이라고 하셨다.
그래서 나중에 배달이 추가되면 정확히 어떻게 구현되는 게 좋을 진 모르겠지만, DELIVERY 라는 상태값은 배달 테이블을 따로 만들어 관리하고 주문과 관련된 배달을 이 배달 테이블에서 끌어와서 조회하게 되는 것 같다.

그리고 프로젝트 가이드에 적혀있는 지역 관련 요구사항이 정확히 어떤 데이터를 가지고 있어야할지 모호해서 질문을 드렸다. 이전 기수를 수료하신 매니저님께서는 시/군/구 도로명 체계를 사용하셨다고 하셨다.

API 명세서

응답 요청을 ResponseEntity 형식으로 맞추기로 해서 그냥 엔티티에 맞는 DTO로 object 하나로 응답하는 명세로 작성했는데,
이후에 status, message 와 data/contents 로 감싼 DTO로 응답하는 형식으로 작성하는게 어떤가 의견이 있어서 아래 사진처럼 수정했다.
그런데 아직 다른 도메인의 API 명세에 응답 방식이 혼용되어있어서 아직 작성이 덜 된것인지, 응답 방식이 바뀌지 않는 것인지 다시 의논이 필요할 것 같다.

프로젝트 생성

우리 팀원중에 git을 잘 쓰시는 분이 계셔 다행이다.
앞으로 GitHub issue를 통해서 커밋과 pr을 하게 된다.
Jira는 경험해봤는데 Github으로 이슈 관리를 한다니 조금 무섭기도(?) 하지만
기존에 Jira를 사용할 땐 jira 와 github 창을 왔다 갔다 하는게 조금 귀찮기도 했다.
Github을 사용한다면 그럴 필요 없게 되어 기대도 된다.

회고

개발 프로젝트를 할때 회의는 해도해도 끝이 없는 것 같다.
튜터님 피드백에 따라 오늘부터 회의록을 작성하기로 했다. 기존 SA 문서에 더해 회의록까지 작성하는게 부담이 큰 게 아닌가 하는 걱정이 되었지만,

하나의 주제에 대해서 뭔가 이야기 할 때 직접 문서를 작성하거나 이해가 간 게 맞는지 다시 확인할 때면 서로 다르게 이해하고있을 때가 많아 그 때 마다 다시 확인하고 넘어가는 일이 많다.
이게 각자 일을 하는데 집중해서 그런지 그동안의 쌓인 피로의 문제인지 의사소통 방식에 문제가 있는 것인지는 모르겠지만 회의록의 필요성을 오늘에서 크게 느낀 것 같다.