우아한 테크코스) Lv3 - 1~2주차 [WAS 구현] 미션 후기, 코드 리뷰

Lv3 과정 소개

학습 목표

• 웹 서버를 직접 만들어 보는 경험을 통해 HTTP에 대한 이해도를 높인다.
• TCP/IP와 같이 다양한 프로토콜을 분석해 네트워크의 기본 역량을 쌓는다.
• 나만의 라이브러리를 직접 구현해 보는 경험을 통해 업무에서 발생하는 중복 코드를 제거하는 역량을 쌓는다.
• 대용량 데이터에 처리에 대한 역량을 쌓는다.
• MVC, DI 컨테이너를 직접 구현해 보는 경험을 통해 Spring 프레임워크의 내부 동작 원리에 대한 이해도를 높인다.
• 성능을 고려해 시스템을 설계하고, 구축하는 경험을 한다.

구성

• 1~2주차 : 웹서버, WAS 구현을 통한 HTTP 이해 + 패킷분석을 통한 네트워크 이해
• 3~4주차 : MVC 프레임워크 구현 + 한대의 서버에 대한 성능 측정, 성능 관련 기본 개념
• 5~6주차 : JDBC 라이브러리 구현 + 대용량 데이터 쿼리 연습, index를 통한 성능 개선 경험
• 7~8주차 : DI 프레임워크 구현 + n대의 서버 확장을 통한 성능 개선 및 시스템 아키텍처 설계
• 9주차 : Buffer

동기부여

나의 인생에서 가장 치열하고, 열심히 살았던 시간으로 만들어라.

레벨3 컨셉 - "바퀴의 재발명"

레벨3 필독서 - 별도 정리

---

Lv3 - 1~2주차 미션 : WAS 구현

https://github.com/woowacourse/jwp-was

학습목표

• 웹 서버 구현을 통해 HTTP 이해도를 높인다.
• 서블릿 컨테이너의 역할과 내부 구조를 이해한다.
• HTTP의 이해도를 높혀 성능 개선할 부분을 찾고 적용할 역량을 쌓는다.
• Packet 구현을 통해 OSI 7 Layer 및 encapsulation, decapsulation 이해도를 높인다.

요약

• HttpRequest/Response, Header, HttpMethod/Status, Cookie/Session, DispatcherServlet역할, 정적/동적 자원 요청을 구분하는 resolver 등 '정말 기본적인' WAS 역할의 서버 코드 구현
• ThreadPool 개념 등장
• Http 요청/응답 처리에 관한 많은 고민과 구현
  • 특히 쿠키와 세션처리도
• 웹 환경에서의 성능 개선
  • 캐싱을 통해 중복 다운로드 제거
  • 압축을 통해 리소스 전송 인코딩을 최적화
  • ...
  • 이 주제는 강의자료 또는 포스팅을 참고하자
• 추가 미션 : 패킷 구현 & 네트워크 학습

회고

• 레벨2의 세부기술적인 미션&학습 진행방식과 다르게, 오랜만의 레벨1의 설계에 대한 고민을 할수있었음 (역할, 추상화, 객체지향 등을 고민하며)
  • 이 과정에서, DI로 테스트하기 힘든 부분을 분리해 최대한 끌어올리는 연습을 다시 한번.
• 전반적으로 미션을 진행하며, Spring과 Servlet 등은 둘째치고 HTTP에 대한 지식과 학습의 필요성을 느낌.
• 이미 구현된 Spring의 HttpRequest라던가 기존 코드를 최대한 안보고 구현해보려 노력했다.
• 레벨2 미션에 비해 개인적으로 좀더 재밌었다. 지금의 나는 특정 기술에 대한 세부적인 지식을 익히는 것보단 설계를 고민하는 데서 좀더 흥미를 느끼나보다.
• 특정 요구사항이 구체적이었던 미션은 아니라서, 나중에 이 글보단 그냥 깃헙들어가서 코드 다시한번 보는게 기억 상기하는데 빠르겠다.

---

내 코드, 피드백 관련

내 코드 package 구조

• toString의 용도가 문득 헷깔려서 질문하고, 확인

• 하드코딩을 피하고 생성자의 인자 순서를 일관된 방식으로 넣고 싶어서, 리플렉션이란 개념을 처음으로 활용해봤는데, 관련된 내용을 찾아보며 리플렉션을 사용할땐 주의해야함을 알수있었다.
  • 참고자료 : 이펙티브 자바 - 리플렉션 대신 인터페이스를 이용하라

• 처음엔 확장자로 Content-Type을 정했다가, Request의 Accept 헤더를 보고 결정하는 방식으로 수정.
  • Tika 쓸땐 속도도 느렸었다.

• 자주 안쓰다보면 까먹게 된다.

• 피드백을 받고 `AbstractController`를 이쁘게 고칠수있었다.
• 이 상태로도 충분히 이쁘긴한데, step2에서 추가로 service의 if문 분기를 없애는 시도도 했다.
• 관련된 내용은 코멘트에 잘 정리되어있어서 생략.

step1

step2

• query string과 request body는 분리해서 관리하는게 맞는 것 같다.

• 고민과, 내 나름의 결론

• 예외처리가 아직 익숙친않다.
  • 다만 현재 내 예외처리에 대한 과한 강박은 조금 덜어도 될것 같다
  • 아직 감이 잘 오진 않지만, 이 자료가 도움이 많이 됬다.

• 처음에 엄청 무겁던 `RequestHandler` 클래스가 리팩토링을 거치며 분리를 거듭해 깔끔해졌다.
  • 그 과정에서 하기전엔 번거롭다고 느끼지만, 객체포장이 주는 이점도 다시한번 느꼈다.
  • 이때의 resolve관련 클래스들은 step2에서 계속해서 리팩토링된다.
  • 설정파일을 통한 관리도 괜찮은 방법인듯.

• 맨 처음에 깊숙히 있던 DataOutputStream을, 리팩토링하며 테스트하기 쉽게 최대한 끌어올렸다. 한편으로 이 피드백처럼 한단계정돈 가지고 들어가서 response가 컨트롤하는것도 괜찮을것같다.

step2

• 생각치 못했던 부분. 싱글톤으로 수정

• 보류된 이슈 / controller(MVC의 컨트롤러가 아닌, 현재 코드의)에선 최대한 비즈니스로직만 수행하고, 쿠키를 굽는 부분은 분리하는게 맞는것같긴하다. 다만 구현이 쉽지않아서 일단은 보류한 상태. 크루들과 얘기해보니, 나같은 경우는 맨처음 RequestHandler에서 Response를 만들때 생성자로 request를 참조하고있으므로, request.getSession()할때 request에 쿠키를 추가하고, 이를 response가 참조해 set-cookie하는 가능성도 있을것같다. 대신 request는 한번 들어오면 값이 바뀔것같진않은데, 이를 수정한다는게 조금 어색하다는 생각. 또는 request가 어떻게 들어오는지와 상관없이 response에서 무조건 쿠키를 설정한다는 크루도?

• 컨트롤러가 ModelAndView를 리턴하도록 수정했다. ViewResolver도 만들어서, 템플릿과 정적 파일 모두에 DI로 활용하도록 수정해보았다. 다른 크루들은 View까지도 만들던데..

---

추가 미션 : 패킷분석을 통한 네트워크 이해

https://github.com/woowacourse/jwp-network

강의자료 참고