코드숨 1주차 ToDo Rest API 만들기

이번 주차는 스프링을 사용하지 않고 java만 이용하여 HttpServer에 TodoList를 만들 수 있는 API를 구현하느 것이 목표였다.

하면서 배웠던 점을 하나하나 정리하면서 다시 복기해보는 시간을 가질려고 한다.

객체의 컨텍스트

1. 하나의 클래스에서 너무 넓은 범위의 업무를 맡는다 는 리뷰를 받았다.
   리뷰를 받았던 이유는 클래스의 객체가 해야할 일을 너무 많이 정의하여 정확한 의도를 파악할 수 없었던 것 같다.
   여기서 생각해야되는 부분은 객체를 생성할 때는 그 클래스가 맡은 일만 정확히 하도록 구현하는것이 중요한데 이부분을 놓쳤던 것 같다.

A의 객체를 B의 클래스에서 사용할 경우 A의 객체에서는 자신이 해야하는 일을 했는가 못했는가에 대한 결과값을 리턴하자.

2. request라는 이름이 붙은 이유는 클라이언트가 요청한 title이라서 그런 것 같습니다. 이 메서드 입장에서는 요청으로 온것인지, 아니면 내부적으로 도메인 로직이 있는지 신경쓰지 않아야 합니다. 이것도 외부 컨텍스트가 내부까지 침입한 것으로 보입니다.

   파라미터의 네이밍 관련 리뷰를 받았다. 객체의 입장에서는 외부의 경로가 어떻게 되었는지 신경을 안쓰고 오로지 자기 자신이 해야할 일만 하면 되는 부분이였다. 메소드를 생성할 때는 파라미터의 이름도 한번 더 생각하여 필요한 이름을 짓을 수 있도록 해봐야겠다.

메소드 통일

회사에서 퇴근하고 과제를 하다보니 하루에 최대 2시간정도 작업을 진행하고 리뷰를 위해 PR을 보낼 수 있었다.
처음에는 2시간이라는 시간에 압박감을 가져 구현에만 신경을 쓴거 같다.
그러다 보니 하나의 기능을 여러가지 메소드로 구현하는 실수를 범하였다.
이부분을 내가 좀 떠 신경쓰고 작성하다보면 불필요한 시간을 없앨 수 있었을텐데.. 부주의했던 것 같다.

앞으로는 중복된 메소드를 만들지 않도록 신경을 써야 겠다.
그래야 리뷰어들에게 불피요한 시간을 사용하지 않을 것 같다.

Stream

리뷰내용중 일부는 스트림의 메소드 관련 부분이였다.
생각보다 내가 자바의 스트림을 활용하지 못하고 있었다. 스트림의 findFirst 와 else 메소드를 적극적으로 활용하면 불필요한 코드작성을 줄일 수 있을 것 같다.

코드숨의 과정이 끝난다면 5월에는 자바8강의를 한번 보고 다시 공부를 진행해야겠다.

try-catch

catch로 빠지게 될 경우 sendResponse를 2번 호출하네요. try catch문을 쓰실 때는 일반적으로 메서드 가장 끝에서 사용하고 뒤에 로직이 오지 않는 것이 좋습니다. 코드의 진행을 이해하기가 매우 어려워요

그리고 tasks요청이 아니면 200을 응답하고 있네요. 처리될 수 없는 요청을 올경우 일반적으로는 404 Not Found를 응답합니다.

위의 내용은 try-catch문 사용관련 리뷰를 여러가지 받았지만 그 중 하나이 예시이다.
try-catch문을 사용했을 때 불필요한 코드가 진행되는 부분도 있었고, 정상적인 케이스가 아닌 구현 코드를 만들기도 했다.

배운점

• Catch문에서 발생하는 Exception은 기존에 되있는 코드보다는 의미있는 예외를 던지는게 분명해야하고,
• Finally 문법은 이해하기 어렵기 때문에 되도록 안쓰는게 낫다.

이 문법을 사용하기 위해서는 생각을 좀 많이 해보고 진행을 해야 겠다. 내가 작성했던 코드는 적합하지 않았던 코드인게 느껴지는 리뷰였다.

Guard clause

처음들었던 개념이였다.
if문을 사용할 때는 정상적이지 않은 케이스를 차례대로 조회하여 예외인 경우 빠르게 종료처리를 하여 불필요한 리소를 줄일 수 있다.
그리고 진짜 의도는 아래에 위치하여 정상적일 경우에만 실행되도록 구현해야 한다.

리뷰 받은 내용을 코드에 적용하면서 점차 성장한다고 느꼈지만 기억에 오래 남지 않았다.
하지만 글로 정리하며 복기를 하다보니 내가 부족한 부분을 한 번 더 인지하면서 진짜로 성장하고 있다는 생각이 들었다.