프로젝트 관련

• 취소, 로그아웃과 같은 중요한 이벤트에 대해서는 알람(alert), 모달 창을 띄운다.

  • 알림을 주는 것이 좋다.
  • 문제풀이 페이지 작성중 뒤로가기, 초기화 등 알림.

• 문제 제출 코드에 오타나, 잘못된 타자에 대해서 validation을 진행해야할 것 같다.

• gist나 파일 첨부로 코드를 제출할 수 있는 방법도 생각하면 좋을 것.

  ⇒ Oauth Scope

• github 페이지와 연동도 된다면 좋지 않을까 생각한다. (배지 생성 등)

• 배포 production에 필요한 환경 변수를 어떻게 관리하는 지

• .env 파일

  • ncloud의 환경변수 저장 방법이 있는 지 찾아보자.

• 피어세션 때 멘토링 방식이 어떤지 물어보자.

  • 시작할때 무슨이야기를 할지 막막하니까 멘토링 이야기로

• 에러 핸들링

• 코드 리뷰 멘토님이 해주신 거 참고

• Naming에 위치에 종속되어있는 정보는 적지 않는다.

• 코드만 보고 어떤 컴포넌트인 지 알 수 있도록 작성을 하는 것이 좋다.

• 위치 + 어떤 컴포넌트다 정도는 기입해야할 듯.

• 자원이 제한된 상태에서 어떻게 최적화를 시켜야할까. 도 고민을 하는 것이 도움이 될 것

  • 트래픽 문제
  • 절약적인 서버 개발자다..?

Git flow

• main 과 dev
  • 계속 해서 살아있는 기준 브랜치
  • release나 hotfix는 사라질 수 있다.
  • main : 현재 본 서버에 배포되어있는 상태
    • 안에서 절대 코드를 손대면 안됨.
  • release : dev 기준으로 생기는 브랜치(=곧 배포될 브랜치)
    • merge가 되면 main dev에 둘다 merge
    • release는 변경 사항이 항상 발생할 수 있다.
  • hot-fix : main 기준으로 생기는 브랜치(실제 배포된 서비스(main)에서 심각한 이슈가 발생했을 때 고치는 브랜치)
  • 기준 브랜치에 머지 되면 사라진다.
  • 서비스가 불가능한 버그
  • main과 dev에서 코드를 절대 수정하진 않음.