• 로그 컨벤션
  • 크리티컬한 것만 error 찍고, 나오면 정합시다!
• Builder 사용 여부
  • 이펙티브 자바 → 파라미터 인자가 많을 때, 빌더 패턴을 고려하라
  • 텔레 스코프 패턴을 이용하면, 생성자만으로 충
  • 규칙을 두어서 문제 상황을 처리하자
    • 필드가 5개 이상이면 빌더 사용

• 총 업무량을 파악할 때의 팁이 있을까요

  • 타겟층이 사용자, 업주, 관리자 → 할게 많다.
  • 디테일 설정을 어떻게 하느냐에 따라 다르다.

• 가장 먼저 해야할 일

  • 레퍼런스로 삼을 서비스가 없으니
  • 최소한 어디까지 할지 기획 디테일을 명확하게 해라!
  • 기획에 시간이 많이 들기에 초반에 이시간을 줄여놔라 → 후반에 개발에 많이 시간을 쓸 수 있음
  • 프론트랑 밀도 있는 시간

• 단어의 의미 명확하게 해라

  • 모두의 생각을 동기화 해야한다.
  • 새로운 개념에 대한 의미 FE, BE 동일하게 인지해야함
    • 최대한 문서화
      • 기록 용도, 증거 용도도 있지만 생각 동기화에도 좋다.
      • 시간이 들지만 길게 보면 빠른 길임.

• FE 랑 기획 이후 API 논의 시점에 BE 가 던져 주지 말고 FE, BE 담당자들끼리 합의

  • FE 가 어떻게 필요한지 BE 는 이렇게 어렵다 등 논의를 함께 해서 같이 만들자
  • FE 가 던져 달라고 해도 같이 하자고 주장해보면 좋음
    • 면접 때 협의 경험 생김
    • 회사의 프로세스도 비슷함
    • 유의미함

• 트러블 슈팅 문서화

  • 어떤 어려움이 있었고 어떻게 풀어냈는지 바로바로 풀어내면 좋음
  • 문제점
    • 각각의 사람들이 어떤 역할을 했는지 보기 어려움
    • 이력서를 보다보면 다 비슷해보임. 차별화되는 포인트가 없음
      • 왜 이런 기획을 하게 되었는지. 어떤 관점에서 생각해냈는지도 잘 정리해보시길!
      • 하고 싶은 아이디어로 하는 것 중요
        • 실제 불편함을 느껴서 기획 → 어필 잘 해보십쇼

• 팀의 유대감이 중요해요

  • 마음을 맞춰가야하는 과정이 필요
  • 어떤 분위기에서, 어떻게 업무를 진행하고 싶은지, 어떤 팀을 만들고 싶은지, 어떤 문화를 구축하고 싶은지 논의해보는 시간 필요

• 많은 기술 경험 보다는 기초가 중요!

  • 많은 기술을 쓰면서 기초를 놓치는 것 보다는 기초를 명확하게 하는 것이 좋다
    • 기초
      • 자바와 스프링을 자바와 스프링답게 쓰는 것
      • 커뮤니케이션 능력 → 상대방의 의도 파악
      • CS 지식들
    • 기술은 사용해야하는 명확한 이유를 가지자
  • 본질은 기술을 사용하기 위함이 아니라 문제를 해결하기 위함이다.

• ci/cd 초반에 하는 거 추천해요

  • 미리 배포해놓고 버그 리포팅

• 스프린트 단위

  • 짧게 가져가서 쫒기는 느낌으로 생산성

• 로그 레벨

  • 로그는 많을 수록 좋지만, 로그 또한 비용이므로 마냥 좋지 않음

  • level: info | error | (debug?, warn ?)

  • info : 실행 흐름을 파악해야 하는 기능들에 대해 사용하면 좋을 것

    • ex) 카카오 페이의 충전 단계별로 info로 남겨서 어떤 단계에서 실패했는지 알기 쉽게

  • error : 절대 에러가 나면 안되는 단계에서, 에러가 나서 빠른 확인이 필요할 때 사용

    • ex) 2시에 반드시 충전되어야 하는데 장애가 났다 → 문자로 발송, 슬랙으로 발송
    • 빠르게 해결해야하진 않지만 넘기면 안되는 runtime error

로그 데이터로 유저 이해하기 | 우아한형제들 기술블로그

GitHub - prgrms-web-devcourse/Team_Sagack_MonthSub_BE: [13조] Backend Repository

• 빌더는 취향 → 기본 프로젝트 방향을 깨지 않는 선에서 개발