이모저모 개발 블로그

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

최근에 1년후 마시가실에 커밋 규칙이 생겼습니다.

From me To me이지만, 습관을 잘 들여놓으면 좋기 때문이죠.

(혹시 누군가 찾아와 제 프로젝트에 대한 관심을 표현했을 때, 제 커밋 규칙과 함께 할 날이 올 수도 있습니다😎.)

커밋 규칙에 맞춰 developer에서 작업하고 commit하고 push하고 pr을 작성하다 문득.. 아주 문득.. Issue와 PR 컨트롤을 잘 하고 있나에 대한 고민이 생겼습니다. 추적할 수 있게 PR에 Issue 번호는 적는데, 뭔가 부족한 듯한 이 느낌..🥸

그래서 브랜치 전략도 바꾸고, Issue도 바꾸고, PR도 바꾸고, 그냥 다 바꾸고.. 바꿨습니다.

지금은 Issue로부터 Branch를 따고, Branch에서 작업을 한 후, PR을 작성하고 최종적으로 작업이 완료되면 branch를 삭제하는 형식으로 운영할 예정입니다.

Issue와 PR이 좀 더 기능 단위로 움직일 수 있도록 신경을 쓰면서 문득 통일감이 부족하다는 생각에 Template도 함께 적용시켜서 진행해보면 좋을 것 같아 이 글을 작성하게 되었습니다.

좋은 Template이 많아 상황에 맞게 요리조리 잘 수정해서 쓰면 좋을 것 같습니다.

  * 참고 자료의 블로그들을 참조하시면, 여러 Template를 만나보실 수 있습니다☺️!

🚨Main Branch에서 작업 🚨

1. Issue Template 생성

해당 Repository → Settings → General → Features → Set up templates → Add template:select → Custom Template

2. 라벨 수정

해당 Repository → Issues → Labels

(허전해 보이는 이유는 저도 이제 시작했기 때문입니다ㅎ_ㅎ)

3. PR Template 생성

해당 Repository → .github 폴더 → pull_request_template.md 직접 생성

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

https://didu-story.tistory.com/278

https://2jinishappy.tistory.com/337

https://yangsosolife.tistory.com/107

https://dev-thinking.tistory.com/m/59

https://docs.github.com/ko/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

System.out.println의 시대는 가라!

log.info의 시대여 오라!

누가 누가 api로 무얼했나를 몰래 시켜보고자 log를 추가하였습니다.

아직 환경이 나누어져 있지 않아서, 추후 local, dev, prod 등으로 환경을 구분하여 log 파일 설정도 발전시켜보면 좋을 것 같습니다⭐!

logback-spring.xml

resources 폴더에 추가

* Color 설정

  * %색상(log 정보) 기재

  * 지원 색상: " %black", "%red", "%green", "%yellow", "%blue", "%magenta", "%cyan", "%white", "%gray", "%boldRed", "%boldGreen", "%boldYellow", "%boldBlue", "%boldMagenta", "%boldCyan", "%boldWhite" and "%highlight"

  * Log를 파일로 출력할 경우,

' ESC[32m '와 같은 글자가 나타나는데 이는 색깔을 나타내기 위한 이스케이프 문자임    파일의 경우에는 색상을 적용하지 않는 패턴을 별도 분리

* ConsoleAppender  * Log를 Console에 출력할 경우에 대한 설정

* RollingFileAppender  * FileAppender와 마찬가지로 파일에 Log를 출력할 경우 사용하는 appender  * FileAppender와 달리 로그를 여러 파일에 나눠서 작성

* SizeAndTimeBasedRollingPolicy

  * RollingPolicy 설정

  * 파일 이름, 최대 파일 크기(해당 크기가 넘어가면 다른 로그 파일이 생성), 최대 보관 일자

UserService.java

* @Slf4j 추가

  * private static final Logger log = LoggerFactory.getLogger(UserService.class);

  * 필요한 곳에 log 설정

    * log 단계

      * TRACE
          * 주로 개발 단계에서 사용
          *  성능 문제를 추적하거나 복잡한 코드의 실행 흐름을 확인할 때 적합
        *  DEBUG
          *  주로 개발 및 테스트 환경에서 사용
          *  개발 및 디버깅을 위해 사용
        *  INFO
          *  주로 운영 환경에서 사용
          *  중요한 이벤트나 시스템 상태 변경(예: 서버 시작, 사용자 로그인)을 기록
          *  프로그램의 주요 흐름을 파악할 때 사용
        * WARN
          *  주로 운영 환경에서 사용
          *  예상치 못한 상황이나 주의가 필요한 상황을 기록
          *  오류는 아니지만, 문제가 발생할 수 있음을 경고

        *  ERROR
          *  주로 운영 환경에서 사용
          *  예외가 발생하거나 시스템이 중단되는 등 심각한 문제를 기록
          *  오류로 인해 서비스의 정상적인 동작이 불가능할 경우 사용

+ Code Style을 자동으로 적용하도록 했는데, xml에서 길이가 길어지니 자동 줄바꿈을 해서 저장하는 문제가 있었습니다.

IntelliJ 기준 Settings - Editor - Code Style - Formatter 탭

Do not Formatter에 특정 파일을 추가할 수 있습니다.

https://hj0216.tistory.com/954

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

https://breakcoding.tistory.com/400

https://goddaehee.tistory.com/206

https://parkstate.tistory.com/31

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

그간 커밋 메시지 안녕하셨는지요..?

전 직관적으로 씁니다.

"JWTProvider: JWT 오류 수정"

하지만, 이제는 깃모지와 함께 헤더만 보고도 유추할 수 있도록 진화하였습니다.

사실 마실가실 리팩토링, 혼자하기 때문에 커밋 메시지나 규칙은 크게 신경쓰지 않았습니다. 왜냐면 From me To me 같은 느낌이랄까요...

혼자하기에 규칙을 쓰지 않는 것보다 오히려 여러 규칙을 적용해볼 수 있는 좋은 기회라 생각하며 커밋 규칙을 (제가 적용할 수 있는 부분에 한해서) 간단히 정리해 보고자 합니다.

Commit = hash + message + author + code snapshot

Message

* 제목(타이틀)과 본문은 개행하여 분리

* 제목 행 끝에 마침표(.) 사용 금지

* 무엇을 왜 했는지 설명

* 하나의 커밋에는 하나의 수정사항, 하나의 이슈를 해결한 내용을 연결

Message 구조

  Type: Subject

  Body

  Footer

Type

✨Feat : 기능 추가                 
🐛Fix : 버그 수정                 
🎨Style : 코드 포맷팅, 함수명 수정 등 
♻️Refactor : 코드 리펙토링              
🧹Chore : 그 외 자잘한 수정          
💡Comment : 주석 추가 및 수정          
✅Test : 테스트 코드 작성 및 수정    
📝Docs : 문서 작성 및 수정          

🌟깃모지를 통해 Type을 효과적으로 드러낼 수 있습니다.

Body

* -로 문장 나누기

* 무엇을 왜 변경했는지 작성

Footer

* Resolves : 문의나, 요청에 의한 이슈에 해당하는 경우 이슈 번호
* Closes : 일반적인 개발과 관련된 이슈에 해당하는 경우 이슈 번호
* Fixes : 버그 픽스, 핫 픽스 관련 이슈에 해당하는 경우 이슈 번호
* See also : 커밋의 이슈와 연관되어 있는 이슈들이 존재 하는 경우, 또는 관련된 이슈들이 있는 경우 이슈 번호

커밋 메시지 예시

✨Feat : #13 회원 로그아웃 기능 추가
- UserController 상 로그아웃 기능 추가

Closes: #13

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

https://insight.infograb.net/blog/2023/04/21/why-commit-convention-is-important/

https://velog.io/@palza4dev/TIL-28.-GitGithub-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80-%EC%9E%91%EC%84%B1%EB%B2%95

https://treasurebear.tistory.com/70

https://hyunjun.kr/21

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

최근에 마실가실 리팩토링 보완점을 들을 수 있던 좋은 기회가 있어서 관련된 내용을 리리팩토링하고 있습니다👩‍🏫!

현재 프로젝트에서는 유효성 검증을 전역으로 하고 있었습니다.

무슨 말이냐면.. SignUpDto에서 이메일, 전화번호, 비밀번호 등을 받을 때, 유효성 검증이 들어가는데 저는

'ValidationUtils'를 통해서 빈 값은 아닌지 형식은 맞는지 검증을 했었죠.

하지만, 회원가입 시 한 번만 쓰이는 Validation은 전역보다는 해당 DTO에서 처리하는 좋은 방법도 있다는 걸 알게 되었는데..

문제는.. 기존에 @RestControllerAdvice 설정들이 움직이지 않는다는 것,,

이 참에 예외 처리를 제대로 정리해 보고자 합니다,,🌟

SignUpRequestDTO.java

* Validation

  * ValidationUtils → Annotation 활용(@NotNull, @Pattern 등)

  * UserType: String → Enum 값 유효성 검사로 변경

🚨 Annotation 사용을 통해 CustomErrorCode의 검증이 이뤄지지 않음

  🔨 이참에 Exception 처리 방식을 공부하면서 고치자

GlobalExceptionHandler.java

* @RestControllerAdvice를 선언하여 여러 컨트롤러에 대해 전역적으로 ExceptionHandler를 적용

  * ExceptionHandler: Exception 클래스들을 속성으로 받아 처리할 예외를 지정할 수 있음

ErrorCode.java

* 클라이언트에게 보내줄 에러 코드를 정의

  * ErrorCode: 인터페이스를 이용해 추상화

  * CommonErrorCode: 애플리케이션에서 전역적으로 사용

  * UserErrorCode: 특정 도메인에 대해 구체적 사용

BusinessException.java

* ErrorCode를 받아서 처리해줄 CustomException class

* RuntimeException을 상속

  * 예외가 발생했을 때, 프로그램을 종료하기보다는 해당 예외를 적절히 처리하여 비즈니스 로직을 올바르게 진행하거나 사용자의 잘못된 요청에 대한 피드백을 제공하는 것이 목표

  🚨 스프링 프레임워크가 제공하는 선언적 트랜잭션(@Transactional)안에서 에러 발생 시 체크 예외는 롤백이 되지 않고, 언체크 예외는 롤백됨

ErrorResponse.java

* 클라이언트에 반환할 ErrorResponse 설정

* ValidationError

  * @Valid를 사용했을 때 에러가 발생한 경우 어느 필드에서 에러가 발생했는지 응답을 위한 내부 정적 클래스

  * FieldError

    * Spring에서 유효성 검사가 실패한 필드에 대한 정보를 제공하는 클래스

GlobalExceptionHandler.java

* ResponseEntityExceptionHandler

  * 스프링 예외에 대한 ExceptionHandler가 모두 구현되어 있음

  * 에러 메세지는 반환하지 않으므로 스프링 예외에 대한 에러 응답을 보내려면 handleExceptionInternal()를 오버라이딩

* @Valid에 의한 MethodArgumentNotValidException

  * @Valid 관련 정보: MethodArgumentNotValidException의 getBindingResult 참조

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

https://mangkyu.tistory.com/205

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

오늘은 잔망과 루피의 이름으로 다른 코드 스타일을 용서하지 않을 예정입니다.

여러명이서 진행한 프로젝트인만큼 파일마다 개성이 뚜렷했는데, 찾아다니면서 맞추기에는 효율도 떨어지고 놓치는 부분도 분명이 있을 것이라 생각했습니다.

또 다른 문제는 제가 가진 코드 컨벤션 같은 것이 없기에 다른 이가 만들어 놓은 포맷팅을 우선 일괄적으로 적용하는 것이 필요하겠다는 판단을 했습니다.

그래서 이번 목표는 다른 이의 코드 스타일을 일괄로 한 번에 적용하자! 입니다🤓!

1. xml 형식의 스타일 가이드를 하나 구해봅니다.

* intelliJ java 기준입니다.

https://github.com/google/styleguide/blob/gh-pages/intellij-java-google-style.xml

https://github.com/woowacourse/woowacourse-docs/blob/main/styleguide/java/intellij-java-wooteco-style.xml

2. IntelliJ에 적용

* Window 기준입니다.

File - Settings - Editor - Code Style - Java

Scheme - 톱니바퀴 - Import Scheme - IntelliJ IDEA code style XML - Apply

3. 코드 저장 시마다 Formmatting 적용 설정

File - Settings - Tools - Actions on Save

* Reformat code: 저장 시마다 formmating 적용

* Optimize imports: 사용하지 않는 import문 제거

🚨 Rearrange code, Run code cleanup: 코드 위치 변경, 불필요한 코드 제거 등의 기능을 제공하지만 사이드 이펙트 우려가 있어 사용하지 않습니다.

4. 전체 파일에 적용

* 개인이 따로 줄 바꾸기 한 게 사라질 수 있으므로 Line Break에 대한 경고창을 확인해야 합니다.

* 개별 파일에서 적용: ctrl + alt + L

* 특정 폴더 내의 모든 파일 적용: Project 창에서 해당 폴더를 클릭한 후 ctrl + alt + L

  🚨 Default로 Clean Up Code가 Check되어있으므로 유의

+ 2024.10.03

Code Style을 자동으로 적용하도록 했는데, xml에서 길이가 길어지니 자동 줄바꿈을 해서 저장하는 문제가 있었습니다.

IntelliJ 기준 Settings - Editor - Code Style - Formatter 탭

Do not Formatter에 특정 파일을 추가할 수 있습니다.

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

https://yeon-kr.tistory.com/197

https://velog.io/@pgmjun/IntelliJ-%EC%BD%94%EB%93%9C-%EC%8A%A4%ED%83%80%EC%9D%BC%EC%9D%84-%EC%84%A4%EC%A0%95%ED%95%B4%EB%B3%B4%EC%9E%90-feat.%EC%9A%B0%ED%85%8C%EC%BD%94