튜터님들의 당부

로그 시스템
버그 리포트

어떤 버그가 났는지 체크를 하나도 못할 것 같아서 이것을 좀 얘기해보려고한다. EC2 이용시 어떤 에러가?

고객 피드백 전에 해야할 것

형철 튜터님

• 고객 피드백 받으면 서버에러가 났을 때 하나도 모를것...
  -> 에러를 터지는거 잘 적어놓기
  어떤 유저가 어떤식의 에러를 경험했는지 잘 적어 놓을 것!
• 스프링에 로그시스템 있음 예) Slf4j 로그시스템을 인터페이스화 해놓은 것)
  실제 구현체는 우리가 등록하는 것에 따라 다르게 작동하는 것이고 slf4j는 인터페이스. log4j2, logback 키워드로 검색해볼것
  로그를 어디에 남기고, 어떤식으로 남기고, 시간 포맷이나 어떤걸 남길것인지 해보기.
  에러 인포정보들을 파일로라도 남기는 것을 해봤으면 함.
  ELK까지는 아니더라도...! 꼭 log4j2, logback 정도는 해보기

민철 튜터님

• 고객한테 피드백을 받으면 우리는 기본적으로 백엔드 개발자니까, 고객분들이 프론트만 보고 참고할 수 있으니까 백엔드적 지식과 백엔드적 코드에서 높은 퀄리티를 디비 트랜젝션, 인증, 배포
  커밋 로그로든 문서가 되었든 이런 부분을 최대한 세세하게 남겨줄것
  디비(관리) 인증 배포는 선택과 집중이 필요. 높은 퀄리티는 해야함

  • 백엔드쪽을 중점적으로 봐주세여! 하고 바라는 부분.

• 사용자를 받을 때는 기획, 행동양식이 있었겠지만 사용자들은 생각보다 예상치 못한 행동으로 예상치 못한 오류를 많이 낸다.
  손님이 왕이라 생각하고, 모든 예외를 예상해서 모두 보완을 해볼것.
  수천명이 사용하면 더 많은 에러가 나타날 수 있음
  적은 범위에서 피드백받은 부분은 모두 예외처리를 할 수 있게 할것.
  그게 어렵다면 어떤 행복을 하다가 어떤 오류가 발생했는지 꼭 정보를 남겨놓을것

• 깃허브 PR 협업 아주 좋다고 생각함. 프로젝트 url을 제출했을 때 현업에서는 굉장히 중요하다고 생각함. 커밋 로그 (커밋 메시지)들을 어멘드옵션? 으로라도 커밋메시지 변경해볼것.

• 동기 비동기에 대한 이해 없이 로컬에서만 돌아간다고 생각해서 배포를 하면 문제가 발생할 수 있음. 코드가 실제로 실행되는 순서에 대한 부분, 순서를 제어할 수 있는 부분에 대한 것도 생각해볼것.

  • A다음 B가 실행된다 생각하고 짠건데 순서가 다를 경우 어떻게 할 것 인지 생각을 잘 해보고. 이부분을 생각하면서 코딩을 해보기
  • 코드 기반 테스팅 코딩 필요

• 커밋메시지 권장 단위 - 이슈 라벨 단위로 정해주는게 좋음.

  • 예를 들어 로그인 로그아웃 여러가지 커밋을 한번에 풀 리퀘스트를 보내면 한번에 하기가 어려움. 문서하나, 버그픽스하나 이렇게 라벨에 맞춰서 풀리퀘스트 하는게 좋음.

시영 튜터님

• 포트폴리오 관점에서 어떤 부분을 보완하는게 좋을지 우선순위 같은 것들을 피드백 할 예정

  • 면접은 혼자 들어가니까 각각의 실력을 쌓는게 중요하다
    고도화를 시키는 것도 중요하다.

• 이력서 관련 질문 환영

• 포폴용과 서비스적으로 만드는건 어떻게 다른가?

  • 단 하나의 주요 기능이라도 단위테스트를 해볼 것.
    • 제가 알고있는 단위테스트는 이런거고, 그래서 이걸 우리 프로젝트에 적용해서 이러한 결과를 알 수 있었습니다.
    • 만약 만명의 동시 접속자가 있을 땐 어떻게 할것인지?
    • 더미데이터 만들어서 해보기
    • 서버 부화테스트는 어려우면 해본 팀한테 물어보기
    • 웹에대한 기본적인 내용
    • 스프링은 어떻게 쓰는지에 대한 내용 -> 우리프로젝트를 중심으로 설명해보기
    • 어쩌구 아키텍쳐 책 한번 해보기.

➲ 참고 자료 : 구글 애널리틱스
➲ 참고 자료 : 배포시 참고자료