💻Today's Schedule
09:00 ~ 10:00 CODEKATA
10:00 ~ 10:45 개인 학습
10:45 ~ 11:15 팀미팅
11:15 ~ 12:00 개인 학습
12:00 ~ 13:00 점심 식사
13:00 ~ 16:00 개인학습
16:00 ~ 17:00 [특강] 베이직
18:00 ~ 19:00 저녁 식사
19:00 ~ 21:00 개인 학습
✍ Today I Learned
CODEKATA
- SQL 문제 풀이 (57번 취소되지 않은 진료 예약 조회하기)
- 알고리즘 (47번 K번째수정렬 )
[프로그래머스/JAVA] K번째수
문제설명배열 array의 i번째 숫자부터 j번째 숫자까지 자르고 정렬했을 때, k번째에 있는 수를 구하려 합니다.예를 들어 array가 [1, 5, 2, 6, 3, 7, 4], i = 2, j = 5, k = 3이라면array의 2번째부터 5번째까지
fargoewave.tistory.com
스케쥴 앱 만들기 (설계하기)
- 제공받은 스프링 강의를 꽤 흥미롭고 재밌게 봤는데, 막상 과제를 시작하려니 0단계에서 부터 막혔다.
- 백엔드 설계 단계를 진행해 본적이 없어서 요구사항을 수행하는데 필요한 학습을 위해 많은 시간투자가 필요했다.
- 우선 요구사항을 정리하면 아래와 같다.
공통 조건
1. 일정 작성, 수정, 조회 시 반환 받은 일정 정보에 비밀번호는 제외해야 합니다.
2. 일정 수정, 삭제 시 선택한 일정의 비밀번호와 요청할 때 함께 보낸 비밀번호가 일치할 경우에만 가능합니다.
3. 비밀번호가 일치하지 않을 경우 적절한 오류 코드 및 메세지를 반환해야 합니다.
4. 3 Layer Architecture 에 따라 각 Layer의 목적에 맞게 개발해야 합니다.
5. CRUD 필수 기능은 모두 데이터베이스 연결 및 JDBC 를 사용해서 개발해야 합니다.
7. JDBC 설정은 강의와 강의에서 제공해주는 코드 스니펫을 참조하셔도 됩니다. ‼️
8
Entity를 그대로 반환하지 말고, DTO에 담아서 반환해주세요!
| 단계 | 기능 | 상세 내용 | 요구사항 |
|---|---|---|---|
| 0단계 | API 명세서 작성 | 각 기능에 대한 API 명세서 작성 | 프로젝트 root에 README.md로 작성 |
| 0단계 | ERD 작성 | 서비스에 필요한 데이터 모델 설계 | 프로젝트 root에 README.md로 작성 |
| 0단계 | SQL 작성 | ERD에 기반한 SQL 작성 | schedule.sql 파일에 작성 |
| 1단계 | 일정 작성 | 일정의 할일, 담당자명, 비밀번호, 작성일/수정일 저장 | 작성 시 수정일은 작성일과 동일 |
| 2단계 | 선택한 일정 조회 | 일정의 고유 ID를 통해 단건 조회 | - |
| 3단계 | 일정 목록 조회 | 수정일, 담당자명으로 일정 목록 조회 | 수정일 기준 내림차순 정렬 |
| 4단계 | 일정 수정 | 일정의 할일, 담당자명 수정 | 비밀번호 일치 시에만 수정 가능, 수정일 갱신 |
| 5단계 | 일정 삭제 | 일정 삭제 기능 | 비밀번호 일치 시에만 삭제 가능 |
| 6단계 | 연관 관계 설정 | 담당자 정보를 분리하여 관리 | 담당자의 고유 식별자 추가, 기존 코드 수정 |
| 7단계 | 페이지네이션 | 일정 목록에 페이지네이션 적용 | 페이지 번호와 크기로 조회 |
| 8단계 | 예외 처리 | 다양한 예외 상황 처리 | HTTP 상태 코드와 메시지 반환 |
| 9단계 | 유효성 검사 | 입력값에 대한 유효성 검사 | 할일 200자 제한, 비밀번호 필수, 이메일 형식 검사 |
- 0단계에서는 리드미 작성을 진행해야 하는데, API 명세와 SQL, ERD 를 포함해야 한다. 0단계 수행을 위해 각 항목을 학습하고 적절한 방법을 찾아 프로젝트를 진행했다.
API 명세
- 필요성
- API 명세는 클라이언트와 서버 간의 통신 방법을 정의하는 문서로 이 명세는 어떤 데이터를 주고받는지, 어떤 HTTP 메소드를 사용하는지, 어떤 응답을 받을 수 있는지에 대해 명확하게 정의한다.
- 프론트엔드와 백엔드 개발자들이 동시에 작업할 수 있고 서로가 어떤 데이터를 주고받을지 명확히 알고 있기 때문에, 의사소통 오류를 줄이고 개발 속도를 높일 수 있다.
- API 문서는 유지보수 단계에서 매우 중요한 역할을 한다. 새로운 개발자가 프로젝트에 참여하더라도, API 명세를 보고 전체 시스템의 흐름을 이해할 수 있다.
- 작성하는 방향/방식
- 일관된 형식: 모든 API 엔드포인트에 대해 일관된 형식으로 문서를 작성해야 한다. 일반적으로 API 이름, HTTP 메소드, URL, 요청 파라미터, 응답 데이터, 상태 코드 등을 포함한다.
- RESTful 설계: RESTful한 방식으로 API를 설계하는 것이 좋다. 즉, 리소스를 URI로 식별하고, 해당 리소스에 대한 작업을 HTTP 메소드로 표현한다.
- RESTful이란 REST 아키텍처 스타일을 준수하여 설계된 시스템이나 API.
- RESTful API는 HTTP 메소드를 사용하여 자원에 접근하고 조작하며, 클라이언트와 서버 간의 통신에서 무상태성을 유지.
- RESTful 디자인은 웹 애플리케이션의 일관성, 확장성, 유지보수성을 높이는 데 중점을 둠.
- 과제 진행
- 프로젝트에서는 일정(Plan)을 생성, 조회, 수정, 삭제하는 기능이 필요하므로, 이 기능들을 RESTful한 방식으로 API 명세를 작성했으며, 각 API 엔드포인트는 기능별로 정의되었으며, HTTP 메소드(GET, POST, PUT, DELETE)를 사용해 리소스에 대한 작업을 표현함
SQL
- 필요성
- SQL은 데이터베이스 구조를 정의하고, 데이터를 조작하는 데 필요한 언어로. 설계 단계에서 SQL을 작성하는 이유는 데이터베이스 스키마를 미리 정의하여 데이터의 저장, 검색, 수정, 삭제를 효율적으로 관리할 수 있도록 하는 것.
- 데이터베이스 설계는 시스템의 성능과 확장성에 직접적인 영향을 미치기 때문에, 초기 설계 단계에서 SQL을 잘 작성하는 것이 중요하다.
- 작성하는 방향/방식:
- 테이블 정의: 각 데이터베이스 테이블의 구조를 정의해야 한다. 이때 각 컬럼의 데이터 타입과 제약 조건을 명확하게 지정한다.
- 정규화: 데이터의 중복을 최소화하고, 테이블 간의 관계를 명확히 하기 위해 데이터베이스 정규화를 적용한다.
- 인덱스와 제약 조건: 검색 성능을 높이기 위해 인덱스를 추가하고, 데이터 무결성을 유지하기 위해 외래 키 제약 조건 등을 설정함.
- 과제 진행
- 프로젝트에서 사용되는 주요 테이블은 plans 테이블이며, 이 테이블은 일정의 내용(todo), 담당자 이름(assignee), 비밀번호(password), 생성일(created_at), 수정일(updated_at)과 같은 필드를 포함한다.
- 단계별로 사용해야 하는 테이블이 다른데, 우선 필수 구현을 해야 하는 1-5 단계까지를 설계 단계로 보고 테이블을 작성했다. 추후 시간이 남는다면 추가요구사항까지 반영해 수정.
- id 필드를 기본 키(Primary Key)로 설정하여 각 일정을 고유하게 식별할 수 있도록 하고, AUTO_INCREMENT를 사용해 일정이 생성될 때마다 고유한 ID 값이 자동으로 증가되도록 함. 다른 필드(todo, assignee, password 등)에 대해서는 명확한 데이터 타입과 NOT NULL 제약 조건을 추가해 데이터 무결성을 보장함.
CREATE TABLE schedules (
id BIGINT AUTO_INCREMENT PRIMARY KEY, -- 각 일정의 고유 식별자 (자동 증가)
todo VARCHAR(200) NOT NULL, -- 할 일의 내용
assignee VARCHAR(20) NOT NULL, -- 담당자 이름
password VARCHAR(20) NOT NULL, -- 일정 수정 및 삭제 시 필요한 비밀번호
created_at DATETIME NOT NULL, -- 일정이 처음 생성된 시각
updated_at DATETIME NOT NULL -- 일정이 마지막으로 수정된 시각
);
ERD (Entity-Relationship Diagram)
- 필요성
- ERD는 데이터베이스 테이블 간의 관계를 시각적으로 표현한 다이어그램으로. 시스템의 데이터 구조를 시각적으로 이해할 수 있게 도와주며, 테이블 간의 관계를 명확하게 정의한다.
- ERD를 통해 데이터 모델을 시각적으로 표현하면, 데이터베이스 설계에 대한 이해도를 높일 수 있다. 또한, 데이터베이스 구조를 설명하거나, 다른 팀원과 논의할 때 매우 유용하다.
- 작성하는 방향/방식:
- 엔티티와 속성: 각 엔티티(테이블)와 그 속성(컬럼)을 정의한다. 각 엔티티는 고유의 주 키(Primary Key)를 가져야 하며, 필요한 경우 외래 키(Foreign Key)로 다른 엔티티와 관계를 맺습니다.
- 관계 정의: 엔티티 간의 관계(1:1, 1, N)를 정의합니다. 각 관계는 현실 세계의 비즈니스 로직을 반영해야 하며, 이를 통해 데이터베이스 구조를 이해하기 쉽게 표현한다.
- 다이어그램 도구 사용: ERD를 작성할 때는 Visual Paradigm, Lucidchart, Draw.io 같은 도구를 사용하여 시각적으로 깔끔한 다이어그램을 생성하는 것이 좋다.
- 과제 진행
- ERD를 작성하는 사이트가 여러가지가 있었다. 그 중에 AQuerry tool과 루시드차트를 선택했고, 둘 다 작성해보며 사용 방법을 익혔다.
- 1-5 단계에서는 담당자(assignee)를 별도의 테이블로 분리하지 않아 관계 정의가 필요하지 않았다.
- 이때 사용하는 약어가 생소해 추가 공부를 진행했다.
| 약어 | 용어 | 설명 |
| PK | Primary Key | 각 레코드를 고유하게 식별하는 열 (중복 불가, NULL 불가) |
| FK | Foreign Key | 다른 테이블의 Primary Key를 참조하여 테이블 간의 관계 정의 |
| AI | Auto Increment | 레코드가 추가될 때 자동으로 증가하는 숫자 값을 생성하는 속성 |
| NN | Not Null | 열에 NULL 값을 허용하지 않는 제약 조건 |
| UQ | Unique | 열의 값이 테이블 내에서 유일함을 보장하는 제약 조건 |
| Default | Default | 값이 입력되지 않았을 때 자동으로 채워지는 기본값 |
| Index | Index | 검색 성능을 향상시키기 위해 특정 열에 대해 생성된 데이터 구조 |
| Check | Check | 열의 값이 특정 조건을 만족하도록 하는 제약 조건 |
📝회고
지난 프로젝트때 다른 조들의 발표를 보며 우리 팀에서 설계 단계를 놓친 것을 파악했다.
그래서 사실상 첫번째 설계인데, 이번 과제의 목표를 추가 구현을 포함해 모든 기능을 완성하는 것으로 생각하고 있어 현재 단계에서 설계를 어떻게 진행해야 하는지 고민했던 것같다.
이전 개인과제에서도 설계단계를 진행하지 않고 스탭별로 계산기를 만들어가다 보니 (근데 이건 과제 목적에 맞게 한 것같다.) 결국 모든 구조를 변경하는 형태로 변경되었다.
그때를 생각하며 이번 과제는 설계단계에 모든 사항을 반영하고자 했으나, 과제 요구사항에 단계별 구현 내용을 commit으로 남겨야 하기 때문에 부적절하다고 생각했다. 그래서 우선 1차 목표를 1~5단계 구현으로 잡고, 이 내용을 토대로 설계를 진행했다.
이전에 이 내용을 공부하고 프로젝트에 응용했으면 어렵지 않게 진행했을 것같은데,
스프링 강의를 재밌게 수강해놓고도 과제의 0단계부터 막힘을 경험하니 꽤 좌절스럽기도 했다.
아무튼.. 하루를 이렇게 써버려서 아쉽지만..
지금 단계를 거쳤으니 다음 프로젝트는 이해하는데 어려움이 없지 않을까?.. ^^..
🔖Tomorrow's Goal
- 개인과제