전체 글

Stateful, Stateless 특징 Stateful 상태를 유지한다. 로그인 세션 등, 상태를 유지해야 하는 경우에 사용한다. Stateless 상태를 유지하지 않는다. 확장에 유리하다. HTTP API 설계 API URI 설계 규칙 최대한 리소스를 기준으로 설계하자. 리소스(명사)와 해당 리소스를 대상으로 하는 행위(동사)를 분리하자. 행위는 HTTP 메서드로 구분하자. 위의 규칙은 이상적인 설계 규칙이고, 필수적으로 지켜야 하는 것은 아님. GET: 리소스 조회 주로 쿼리 파라미터를 통해 서버로 요청 데이터 전달 주로 조회에 사용한다. GET으로 조회하면 데이터를 캐싱해둬서 조회에 유리함. POST: 요청 데이터 처리, 주로 등록에 사용 메시지 바디를 통해 서버로 요청 데이터 전달 주로 신규 리..

오늘 한 일 https://learngitbranching.js.org/?locale=ko에서 git을 사용하는 여러 문제 상황을 게임처럼 풀어봤다. 잘 몰랐던 git의 동작방식, rebase를 자세히 알 수 있었다. 팀 프로젝트 회고를 진행했다. 저번 KPT 회고에서 시도하고 싶은 것이 6개였는데 이번 프로젝트를 진행하며 4개를 적용해서 좋았다. 다음 프로젝트에선 더 깔끔하게 협업할 수 있겠다. 현대오토에버 자소서 작성했다. 저번에 코테 봤을 때 쉽다고 생각했는데 떨어진걸 보면 뭔가 문제가 있었던 것 같다. 이번엔 더 잘 준비해야지..ㅠㅠ

오늘 한 일 팀 프로젝트의 클래스 다이어그램을 정리했다. 다이어그램으로 보니까 클래스의 의존관계가 복잡하게 얽혀서 클래스 역할 분리가 깔끔하게 이루어지지 못한 것을 알 수 있었다. 설계부터 깔끔하게 하고 개발하던지, 아니면 종종 다이어그램으로 만들어서 잘 진행하고 있는지 정리하면서 만들면 프로젝트에 도움이 될 것 같다.

오늘 한 일 팀 프로젝트를 리팩토링했다. 팀원들과 함께 진행했는데, 내가 키보드를 잡고 화면을 공유해서 함께 얘기하면서 했다. 의견을 바로 공유하면서 리팩토링 하니까 같은 코드에 대한 다른 분들의 생각도 알 수 있어서 좋았다. 조건문을 의미 있는 메서드 이름을 사용해서 추출했다. 주로 유효성을 검증하는 조건들을 isValid* 메서드 이름으로 많이 바꿨다. 프로그램 루프를 수정했다. 팀원분이 기존에 작성하신 코드는 한 프로세스가 끝나면 메인 프로세스 메서드를 다시 호출하는 방식이라 프로그램의 흐름을 처음에는 이해하기 어려웠다. 그래서 while로 감싼 try 블록 안에서 메인 프로세스를 실행하고, 예외를 처리하는 방식으로 변경했다. 클래스가 한 가지 역할만 하도록 분리했다. 기존의 코드는 한 클래스 내에..

오늘 한 일 Spring boot에서 Bean validation 하는 방법을 공부했다. @Valid, @ControllerAdvice를 사용해서 예외를 핸들링하는 방법을 배우고 프로젝트에 적용했다. @Validated랑 validator 인터페이스를 사용하는 것도 찾아보고 정리하는 글 써야지. 팀 프로젝트로 간단한 호텔 CUI 프로그램을 만들고 있는데, 팀원분이 main 브랜치에 PR할 때 커밋 히스토리가 달라서 PR이 안되는 것을 로컬에서 main 브랜치를 pull 하고 동기화해서 해결하는데 도움을 드렸다.

오늘 한 일 Git / Github 협업할 때 main에 바로 merge 하지말고, dev 브랜치를 기본 브랜치로 설정하고 로컬에서 dev와 병합해서 충돌이 발생하면 해결하고 push, pr 하라고 배웠다. 좋은 방식인 것 같다. 팀 프로젝트 과제가 새로 나왔다. 작은 호텔 예약 프로그램을 CUI로 만드는 것인데, 회의하면서 요구사항을 분석하고 도메인을 설계했다. 내일 다 만들어야지.. 간단하게 코드리뷰를 하고 통과하면 merge 하면서 소소하게 협업을 했다.