qna 피드백 (미션-3)

글또

Gisungcu 2021. 3. 13. 22:05

미션 3을 진행하며 받은 피드백을 기록해 보자.

꼼꼼히 봐주시는 디온이 전담되었다.

처음에 33개의 피드백을 보고 아찔해졌지만 많은 부분을 신경 쓰지 않은 자신을 돌아보기도 했다.

final은 나에겐 익숙지 않았다. 말하자면 굳이? 이런 생각이 강했다. 이미 private로 설정되어있고 내가 굳이 setter를 설정해 주지 않으면 바뀌지 않을 거라고 생각하고 있었다.

내 생각을 정리하고 댓글을 달려고 공부를 해보니 결론은 final을 다는 게 좋다는 거다.

다른 누군가나 미래의 내가 변경하지 말라고 알려 줄 수 있고, 확실치는 않지만 리플렉션으로 들어와도 막을 수 있을 거 같다.

어노테이션을 타고 들어가 보니 기본값은 String [] {}였다.

배열로 받는 게 신기했다. 내부적으로 / 을 기준으로 잘라주고 그걸 PathVariable이 이용하나?

구글링을 해봐도 나오지 않아 동작 원리는 모르겠다.

분기문 처리 관련 피드백을 받았을 때는 처음에는 막막했다.

내 생각에는 login시에는 로그인 실패/ 로그인 성공 이렇게 분기가 존재해야 하고 이것은 피할 수 없다고 생각했다.

근데 디온이 말하기를 로그인 실패는 일반적인 로직으로 생각하지 말라는 것이다.

이렇게 생각하면 로그인 실패는 예외를 발생시키고 비즈니스 로직은 더 깔끔해진다.

그래서 이참에 ExceptionHandler를 만들고 이 곳에서 예외를 처리하도록 하니 많은 중복 코드 (로그인 여부 검증)

코드가 떨어져 나갔다.

cheese10yun.github.io

비즈니스 로직에서 일일이 예외상황을 처리하면 코드의 가독성이 떨어지니 예외를 적극 이용하자는 거다.

하드 코딩된 sessionedUser를 상수로 정의해 놓은 게 있었는데 쓰지를 않았었다..

바로 바꿔 줬다.

로그아웃 로직을 get으로 받고 있었는데 post로 변경해보자는 의견이었다.

stack overflow를 보면 post가 더 안전하다고 하니 바꾸라고 한다.

post는 db의 쓰기 기능을 할 때 사용하는 약속으로 알고 있었는데, 아직도 어렵다.

아직도 url conventional은 익숙지가 않다.

이 것도 따로 글로 정리해야겠다.

UserValidation class는 user의 필드에 null이 있는지 검증하는 util class다.

이런 util, unity class는 행위자로 작명을 하도록 하자. 아니면 뒤에 utils라고 명시를 하던가.

작명은 어렵다. 내가 자주 사용하는 작명법이다. find~, get~.

앞으로는 피하도록 하자. 내가 생각해 봐도 저 변수명은 메서드일 때가 더 어울린다.

null return은 위험하다. 차라리 예외를 발생시키자.

저 null이 어디까지 사용될지는 알 수 가없다.

util class는 인스턴스로 못 만들게 private 생성자를 정의해 놓자.

title이 비었으면 NPE를 리턴했었는데 좋지 않다고 한다.

custom예외는 적게 사용하라는 생각이 박혀 있어 만들지 않았는데,

미션 4 피드백에서도 custom예외를 만들라는 피드백을 받아서 이제는 만들어 사용하고 있다.