오전에는 어제 작성하던 샘플 소스를 정리하고 QueryDSL로 Q객체가 생기는 것 까지 확인했다. 스트레스 조금 받긴 하지만 스프링 세팅은 너무 재밌다. 생각지도 못한 부분에서 문제가 발생하고 해결된다. 여러가지 지식들을 한군데로 모으는 느낌이다.
오후 부터는 피드백 받은 부분을 수정했다. 수정사항이 꽤나 많았는데 최대한 꼼꼼하게 하려고 노력했다. 하지만 너무 잘하려고 했던 탓인지 오버엔지니어링이 있었나보다. 리뷰어께서 해준 것 보다 더 앞서나가 생각을 해버렸다. 어떤 의도에서 말씀해주셨는지 확인하고 다시 읽어보니 이해가 된다. 단순하게 생각하되, 꼼꼼히 읽자.
BufferedReader를 close해줘야하는 이유에 관한 질문도 있었다. 질문이라기 보다는 학습 키워드를 받은 것에 가깝긴 하다. 어쨌든, main에서 IO를 다룰때 main이 종료되면 자연스럽게 종료되겠지 라는 생각으로 close를 하지 않았었다. 여러가지 예제를 살펴보다가 오라클에 나와있는 설명서를 읽어봤는데, main에서도 아주 예쁘게^^ close 해주고 있었다. 설명에서는 IO 객체는 반드시 close해주라고 당부한다. 해당 내용이 궁금해서 여기 저기 찾아보던 중 IO작업을 하려면 커널에서 리소스를 할당해줘야 하는데, close를 하지 않으면 할당이 해제되지 않는다고 한다. 물론 내가 처음 생각했던 것 처럼 JVM이 프로세스가 종료될때 자동으로 할당을 해제해주긴 하겠지만, 그래도 close를 꼭 해주는 것이 안전하다고 한다. 알 수 없는 이유로 IDE만 종료되고 내부의 JVM은 살아있을 때 해당 경우가 발생할 수 있지 않을까 싶다.
I/O 객체들은 현재 사용하고 있는 것만 close 해주면 내부적으로 상위 객체들도 함께 close 해줄 수 있도록 작성되어있다. try-with-resource는 AutoClosable 인터페이스를 구현할 경우 사용할 수 있는데, 필요한 객체들은 모두 구현하고 있다. 스택 오버 플로우를 보니 저 인터페이스 때문에 자동으로 close를 해주는줄 아는 사람도 있었다...
Scanner와 BufferedReader의 속도차이는 Scanner 내부에서 문자열 처리를 위해 Pattern과 Matcher를 사용하기 때문이다. 즉 정규식을 사용한다. 굳이 내부까지 찾아본 이유는 Scanner의 설명에 버퍼가 사용된다고 되어있었기 때문이다. 속도가 큰 차이로 나는 이유가 버퍼의 유무라고 생각했는데 아니었다. 차이점은 둘 다 버퍼를 사용하긴 하지만, Scanner는 버퍼를 논리적인 개념으로 잡아놓고 정규식에서 몇 개씩 잘라서 판단할지를 정한다. 반면 BufferedReader는 일반적인 I/O를 처리하는 것 처럼 작성되어 있다. 이외에도 찾아보다가 Console 객체를 봤는데, 다음에 생각나면 가지고 놀아봐야겠다. 비교적 최근에 만들어진 것이라 그런지, 아니면 별로 효용성이 없어서 그런지 처음 본다.
gradle dependency 맨 마지막에 classifier라는 것이 붙는다. 이번에 처음 알게 됐는데, 내가 공식문서를 잘 안읽는구나 하고 새삼 느꼈다. 특히 기존에 주먹구구식으로 알게 된 것들은 잘 알고있다고 착각하고 안보는 경향이 있는 것 같다. 조심해야겠다.
롬복의 RequiredArgsConstructor 어노테이션을 이용하여 생성자 DI를 하는 방식이 좋아보였다. 바로 차용했는데, 테스트가 잘 되지 않았다. 이유는 Mockito의 InjectMock이 필드에 새로 주입이 가능할때만 객체를 넣어주기 때문이다. final 필드로 DI를 진행하면 이후부터는 새롭게 주입이 불가능하다. 스펙이 그렇게 돼있다고 한다. BeforeEach에서 수동으로 주입 해주는 것으로 해결했다.
미션3를 완료하고 샘플소스를 원하던 목표만큼 작성했다. 스프링 샘플을 이래저래 살펴보다가 BindingResult를 고려하지 않고 있었다는 사실을 깨달았다. 이외에도 예외처리나 Response 객체도 잡아야 한다. Swagger 설정도 해야하는데 이것 저것 따지다보니 생각보다 할 일이 훨씬 많은 것 같다. db설정을 차후로 미루는게 좋을 것 같다.
미션3에서 변경사항이 많이 생기니 리베이스하는데 조금 애를 먹었다. 프로그램 자체 규모가 그렇게 크지 않아 치명적이지는 않았지만, 반대의 경우 리베이스는 신중히 결정해야 할 것 같다. 특히나 커밋이 많이 쌓였을 경우 더더욱.
아쉬운 점
JVM 공부를 또 미루게 됐다. 수업시간에 1/4/7 공부법을 들은 것 같은데 강제로 수행하게 됐다. 😅