> For the complete documentation index, see [llms.txt](https://jinwon-yoon.gitbook.io/jinonys-blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jinwon-yoon.gitbook.io/jinonys-blog/daily-log/2023.04.29.md).

# 2023.04.29

일일 회고 255일차

## 할일 및 한일&#x20;

* [x] 알고리즘 문제 풀이&#x20;
* [x] 캡스톤 프로젝트 Swagger 적용하기&#x20;

## 경험 및 배움&#x20;

### 알고리즘 문제 풀이&#x20;

오늘도 코테를 대비하여 알고리즘 문제 풀이를 진행하였다.

**"해시" 부분의 "완주하지 못한 선수"**&#xB97C; 풀어보았다.

문제 자체는 쉬워보였지만, 풀이는 막상 그렇지 않았다.

중복이 허용되니 `HashSet` 은 아니고, `HashMap` 을 사용해야 하는데 메서드도 잘 모르고, 학습이 덜 되었다.

그래서 배열이나 리스트를 사용해서 풀이해보려 했는데 시간 초과가 뜨는 등 잘 해결이 되지 않았다.

배열이나 리스트를 사용해서 풀거면 시간을 생각해서 우선 정렬을 먼저 해줘야 하는데, 그것을 생각하지 못했다!

다음부터는 같은 경우가 있으면 정렬부터 생각을 해야 겠다.

{% embed url="<https://school.programmers.co.kr/learn/courses/30/lessons/42576>" %}

또한, 다른 문제도 풀어보려고 하다가 어려워서 손도 대지 못했다.. 큰일이다.

### 캡스톤 프로젝트 Swagger 적용하기&#x20;

그리고 캡스톤 프로젝트에 Swagger를 적용해보았다.

Swagger은 연구실 동료가 커피챗을 다녀온 후 들은 피드백인데, 나도 따라서 적용해보았다.

우선 API 명세를 자동으로 해준다는 점이 좋았다.

요청과 응답 형태를 변경한다거나, API를 변경하고 추가할 때마다 나는 기존의 노션 페이지에 계속해서 수정을 해야 했다.

하지만, **Swagger를 사용하면 프론트와의 회의에서도 가독성이 좋아질 뿐더러, 자동으로 API 명세를 관리해준다!**

요긴하게 잘 사용할 것 같지만, 비즈니스 로직에 Swagger 관련 코드가 너무 많이 개입 한다는 문제점이 있다.

실제로, 컨트롤러의 길이가 2배가 넘게 길어졌고, 배보다 배꼽이 더 큰 상황인 것 같기도하다.

따라서, RestDocs를 한 번 공부해서 다시 리팩토링 해보고싶다.

{% embed url="<https://github.com/Jinwon-Dev/santa-clothes-backend/commit/cb7ecf213fd047309ff56a947564427aa27b6127>" %}

## 개선 및 목표&#x20;

* 내일도 역시 캡스톤 및 알고리즘 풀이를 하자.&#x20;
