[Week2] 멘토링

BE - ERD 점검

생성일과 수정일

이런 것들을 자주 사용한다

• create_at
• update_at

Role

enum도 좋지만, Int를 이용하여 권한이 클수록 큰 값을 갖도록 한다면 숫자 비교로 권한 부여를 하기 수월할 것이다.

TypeORM으로 변경한 이유?

→ 성능 상 이유(프리즈마는 2번 날리더라) + 스키마 정의 언어가 따로 있었음

⇒ 블로그에 글을 남겨라 (기술 문서) 나중에 발표라던가 좋은 의미가 될 것이다.

기타 질문?

레퍼런스의 코드가 너무 어려울 때, 이것들을 보는 팁은?

• 시작점이 무엇인지 찾아보자. (Entry Point를 보자.)
  • JS라면 index.js라거나
  • 한 클래스를 시작으로 상속받는 클래스가 무엇이고, 내용물이 무엇인지 하나하나 분석해보는 것도 좋은 방법이다.
  • 이런 질문 하나하나를 문서를 기록하자

하나의 이슈 내에 협업 상 중요한 것들과 한 측면에서만 중요한 것들이 뭉쳐있을 경우, 어떻게 하는 편이 좋을까?

• 일단 협업 상 중요한 것들을 먼저 제공해주자.
• API 교환을 할 경우,
  • 프론트에서 대략적인 구조를 작성하고, 백엔드에서 맞추어주거나
  • 백엔드에서 대략적인 화면 구조를 보고 API 문서를 작성해서 주는 방법도 있음.
• 일단 서로 많이 논의해서 결정하고, 서로 배려해주자.

만약 의존성이 엮여있는 상황에서, 서로 협업하려면 어떻게 하나?

• 의존성이 있는 경우면 어쩔 수 없이 기다려야하고, 계속 쪼아줘야 함. 기능이 완료되면 dev에 머지시키고 그걸 필요한 feat로 머지해서 써야 함. feat 끼리 머지하면 절대로 안된다.
• 의존성 없는 것들을 먼저 해라. 하는 중에 종료되면 다행.

Swagger 어떻나?

• 좋긴 한데, 자동화를 해주려면 세세한 설정이 뒤따르는데, 그런 설정이 너무 많아서 비추천하긴 함. 개인 취향의 영역이기에 잘 선택하면 된다.

만약 부득이하게 개발하던 컴포넌트를 합쳐야한다면 어떻게 해야할까?

• 이런 경우는 부득이하게 feat끼리 합쳐야할 것 같은데?