최세민 4주차 학습일지 ‐ WAS (3)

4주차 회고

느리더라도 확실하게

제가 캠프에서 이루고자 했던 목표는 '모르는 것은 빠짐 없이 학습하고 요구사항을 모두 완성하자'였던것 같습니다. 요구사항이 상대적으로 간단했던 1~2주차에는 공부와 구조를 고민하면서 미션을 수행할 수 있었습니다. 하지만 요구사항이 복잡했던 3주차에는 기능 구현에만 급급해졌고 코드의 퀄리티가 무너졌을 뿐만아니라 학습한 내용도 별로 없었습니다. 미션을 다 한 순간에는 미션 완료라는 목표를 이뤘다는 점에서는 성취감을 느꼈지만, 돌이켜봤을 때 허무감을 느꼈던 것 같습니다.

앞으로 남은 미션 1개, 프로젝트 한 번만 남았지만 우아한테크캠프에서 더 많은 것을 남겨갈 수 있는 방향으로 구현이 좀 느리더라도 공부하는 시간을 하루에 최소 두시간씩 할당해서 진행하려고 합니다.

WAS 미션 아쉬운 점

요청 해석을 비동기로 할 수 있지 않을까?

현재 로직은 하나의 요청을 하나의 쓰레드에서 전체적으로 처리하게 되어있습니다. 하지만 요청이 큰 경우 (File I/O) Stream으로부터 데이터를 읽고 처리하는데 지연이 생길 수 있습니다. 따라서 비동기로 CompletableFuture를 이용해 HttpRequest를 반환받아 서비스로직을 처리하도록 했으면 더 좋았을 것 같습니다.

CSV JDBC Driver

제한된 시간에 미션 완료만을 목표로 구현하다보니 버그도 많고 코드 퀄리티도 낮았던 것 같습니다. 특히 다음과 같은 부분을 신경쓰지 못한 점이 아쉽습니다.

• Jdbc 구현 구조
• 테이블 제약조건
• 많은 데이터가 저장되었을 때 효율적 처리 추후 여유가 생긴다면 위와 같은 부분도 고민해보려고 합니다.

학습 내용

ContentType: multipart/form-data

multipart/form-data ContentType은 파일과 텍스트를 혼합해서 요청할 수 있는 형식의 요청입니다. multipart/form-data 의 ContentType 헤더에는 다음과 같은 boundary 인자가 존재합니다. Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW boundary의 역할은 텍스트와 파일 필드를 구분할 수 있는 역할을 합니다.

BufferedReader/InputStream 의 성능

Buffer에서 한글자씩 읽으면 계속 I/O를 통해 읽고 남은 부분의 버퍼를 채우는가?

그렇지 않습니다. Buffered 구현체는 효율적으로 버퍼를 사용하고 System I/O 가 최소한으로 발생하도록 하기 때문에 버퍼에 더이상 읽을 데이터가 없을 때 I/O가 발생합니다.

getBytes(Charset charset), new String(byte[] bytes, Charset charset)

• getBytes(Charset charset) 메소드는 문자열을 요청된 Charset으로 변경합니다. 실제 바이트 데이터가 변경됩니다.
• new String(byte[] bytes, Charset charset) 메소드는 주어진 byte를 어떤 charset으로 해석할 지 지정하는 메소드입니다. 실제 바이트 데이터가 변경되지 않습니다.