[오늘까지 한 것]

1.2번 발표 시범 및 코드 리뷰 방법 정리해가기

• 첫번째 발표
  대상 : 스프링 및 서버를 모르는 프론트 지망생
  시간 분배 : 25분 스프링 전반 설명 및 5분 코드 구조 설명
  피드백 : 스프링 설명이 너무 어렵다. 비유로 설명해달라. 코드 설명이 너무 짧아서 리뷰를 못하겠다.
  멘토님 피드백 : 스프링을 모르니까 비유로 설명해 달라고 하지.
• 두번째 발표
  대상 : 스프링을 써본 적 있는 카뎃 한 분, 만렙 개발자 두 분.
  시간 분배 : 5분 스프링 전반 설명 20분 코드 구조 설명
  피드백 : (스프링 설명에 대한 언급 없음) 코드를 자랑하러 온 것 같다. 무엇을 리뷰받고 싶은지가 명확하지 않다. 리뷰를 너무 코드에 국한해서 생각하는 것 같다.(이후 어플리케이션에서, 데이터에서 어떤 식으로 문서화가 이뤄지고 로직에 대해서 다양한 관점으로 리뷰가 이루어지는 사례를 들음.) 그림을 그리면서 설명하니까 집중력 떨어진다.시각 자료는 미리 문서화해라.
  멘토님 피드백 : 스프링을 이미 아니까 당연히 언급이 없지. 코드 리뷰도 대상이 누구인지에 따라 설명이 당연히 달라져야 한다.
• 추가 피드백:
  document root home directory를 모른다. 실서버를 구축해보지 않아서 그래. 스프링부트로만 보면 기본으로 설정해주니까 관심이 없었을 거다. 참조
  

2.에러 핸들링

• 보이는 선에선 다 해줌

Tip.
1. TDD는 시퀀스 다이어그램 그리면서, 페어 프로그래밍 하면서 코드로 옮겨보면서 구조 잡는 것이다.
2. 에러를 해당 함수에서 처리할 수도 있고 밖을 낼 수도 있다.
3. 로그에 어떻게 남겨야 디버깅하기 좋을까 -> 지금 배가 아플 때 이유가 한가지가 아니듯 그 상황을 전부 세세하게 적어야 한다.
4. 시퀀스 다이어그램에 코드를 라인바이 라인으로 다 적을 수 없으니까(가독성과 공간 문제) 코드박스로 묶어서 분리해라.
5. 함수 처리 결과 true or false(ex. 예외로 빠진다. )로 판명이 나면
6. jpa에서 save한 후 save한 데이터를 통째로 가져오면 2 sequence가 일어나는 것이고(insert, select)이미 저장한 데이터가 로컬에 있는 상태에서 똑같은 내용의 공간을 또 할애하는 것이므로 아름답지 않다. save 후 저장한놈의 아이디만 가져올 수 있게 해라.
7. error class를 최상위에 둬서( + 비즈니스 로직에 dependant한 클래스도 추가로 해서) 에러 핸들링 부분과 비즈니스 로직을 분리할 수 있다. (에러 대응 메뉴얼)
8. 용도에 따라 log파일을 분리할 수 있다.
9. 에러가 터지면 시스템이 아웃된다.(홀리몰리)
10. 게임에서는 시계열 데이터로 사건의 순서를 정렬하지 않고(stack) 링크드 리스트 형태로 이전 사건 형태를 기억하는 방식으로 새로운 사건을 저장한다. (지하철에서 게임하다가 밖으로 나오면 wifi(내부망)에서 LTE(외부망)으로 바뀐다.이 때 ap가 다르기 때문에(wifi기기의 ap -> 송신기의 ap) 사용하는 시간 서버도 다르다. 즉 시간 서버가 달라서 그 순간 지하철 서버의 시간과 송신기 서버의 시간이 다를 수 있다.시간이 역전되어 저장될수도 있다는 말이다. )
11. 에러 핸들링 상황을 엑셀로 정리해보자

할 일
1. 시퀀스 다이어그램 그리면서 리팩토링 하기
2. 로그 파일 용도에 따라 분리하기
3. 에러 핸들링 상황 엑셀에 정리하기