전에 있던 개발자분이 Spring Security에서 제공하는 OAuth 2.0 라이브러리를 사용하셨는데, 이는 내가 아직 사용해 보지 못한 것이다. 그래서 Spring Security 공식 문서를 보면서 이전의 코드를 이해하기 위해 노력하고 있다.
AS-IS 코드 리팩토링
리팩토링해야 할 것들이 몇몇 눈에 띈다.
서비스 객체들이 ApiBasicResponse 객체를 반환하고 있는데, 이럴 경우 서비스 레이어가 Web 기술에 종속성을 가지게 된다. 또한 서비스 객체 간에 의존 관계가 필요할 경우, ApiBasicResponse를 기반으로 서로 메시지를 주고받게 되는데... 적절치 않음
MemberController에서 Token Refreshing을 하고 있는데, 내 생각엔 Auth용 Controller를 따로 정의하는 게 좋을 것 같다. 그리고 Authentication/Authorization endpoint를 모두 auth 모듈 안에서 수행하는 게 좋을 것 같다.
ERD 재정의
main 브랜치 만들기
딱히 지금 해야 하는 건 아니나... 그래도 만들어두는 게 좋을 듯함
작업 통합은 develop 브랜치에서 하고 main 브랜치는 배포용으로 만들어두는 게 좋을 듯하다. (해결됨)
GitHub 권한 점검
main 브랜치를 만들어서 push를 해 봤더니 403 에러가 떴다.. 권한이 없나 보다. 그래서 필요한 권한을 점검하고 팀장님께 권한 달라고 요청해야겠다. (해결됨)
백엔드 개발자분이 합류할 경우
[x] Git 전략 정하기 (Git-Flow, GitHub-Flow 등)
[x] 커밋 컨벤션 정하기
[x] 이슈 템플릿, 풀 리퀘스트 템플릿 정하기
[x] 코딩 컨벤션 정하기
[x] 어떻게 작업을 진행할지 정하기
[ ] 아키텍처 정하기 (Monolithic으로 할 것인지, MSA를 시도해 볼 것인지... MSA의 경우 내가 좀 더 공부를 하긴 해야 함)
AS-IS 코드 분석
전에 있던 개발자분이 Spring Security에서 제공하는 OAuth 2.0 라이브러리를 사용하셨는데, 이는 내가 아직 사용해 보지 못한 것이다. 그래서 Spring Security 공식 문서를 보면서 이전의 코드를 이해하기 위해 노력하고 있다.
AS-IS 코드 리팩토링
리팩토링해야 할 것들이 몇몇 눈에 띈다.
서비스 객체들이 ApiBasicResponse 객체를 반환하고 있는데, 이럴 경우 서비스 레이어가 Web 기술에 종속성을 가지게 된다. 또한 서비스 객체 간에 의존 관계가 필요할 경우, ApiBasicResponse를 기반으로 서로 메시지를 주고받게 되는데... 적절치 않음
MemberController
에서 Token Refreshing을 하고 있는데, 내 생각엔 Auth용 Controller를 따로 정의하는 게 좋을 것 같다. 그리고 Authentication/Authorization endpoint를 모두 auth 모듈 안에서 수행하는 게 좋을 것 같다.ERD 재정의
main 브랜치 만들기
딱히 지금 해야 하는 건 아니나... 그래도 만들어두는 게 좋을 듯함 작업 통합은 develop 브랜치에서 하고 main 브랜치는 배포용으로 만들어두는 게 좋을 듯하다. (해결됨)
GitHub 권한 점검
main 브랜치를 만들어서 push를 해 봤더니 403 에러가 떴다.. 권한이 없나 보다. 그래서 필요한 권한을 점검하고 팀장님께 권한 달라고 요청해야겠다. (해결됨)
백엔드 개발자분이 합류할 경우