Spring F/W 없는 API 개발

이 글은 필자의 이전 블로그인 https://velog.io/@beomdrive/CodeSoom-1에서 핵심 내용을 중심으로 요약해서 가져왔습니다.

 

"개발"의 시작

2022년 10월 10일 월요일, 회사를 계속 다니고 있었다면 꿀 같은 연휴를 만끽하고 있을 대체 공휴일에 코드숨이 시작되었다.
8주간 코드 리뷰를 받으며 그토록 배우고 싶었던 Test Code와 JPA까지 학습할 수 있는 과정이라 매우 기대하며 강의를 듣기 시작했다.

 

코드숨 과정을 추천해준 지인이 말했듯이 떠먹여 주는 식이 아니라, “실습 중심”의 교육답게 일정 부분만 알려주고 나머지는 과제로 해오는 미션을 받았다. 1주차의 미션은 Framework 없이 Java를 이용하여 간단한 API CRUD를 구현하는 미션이었다.

실무를 할 때 공장처럼 질리도록 만들어봤으니 자신 있게 시작했다.

“엥….?”
웬걸, 익숙한 Spring 없이 생판 처음부터 짜려고 하니까 머릿속이 하얘졌다.

그날 작업한 부분을 오후 9시까지 PR을 날려야 리뷰를 받을 수 있기에 빠르게 기능 구현 중심으로 코드를 작성했다.
그리고 떨리는 마음으로 첫 번째 PR을 날렸다.

 

리뷰어님은 평소에 이미 여러 지인분들을 통해 듣기도 하고, 구글링하면서도 몇 번 블로그에서 본 기계 인간 이종립님(JohnGrib)이셨다.
무척 영광이기도 하고 내적 반가움도 있고, 여러 복잡한 감정을 갖고 달아주신 리뷰를 보기 시작했다.

 

기능 구현에만 집중하다 보니 이건 뭐, 내가 봐도 읽을 수 있는 메서드가 아니었다.

이뿐만이 아니었다. 리뷰를 계속해서 읽어 내려가다 보니, 인지하고 있었지만 “구현 먼저 빠르게 하고 리팩토링하자”라고 넘어갔던 부분들을 제외하고도 미처 생각하지 못한 것들을 아주 많이 찾아주셨다.
다음날부터는 계속해서 리팩토링을 중심으로 코드를 작성했다.

Spring 없이 순수 Java로 API를 만드는 것이 처음이라 신경 쓸 게 너무 많았다.
한편으로는 평소에 Spring이 지원해주는 편한 기능들을 아무 생각 없이 사용했다는 것이 많이 느껴졌다.
왜 이제껏 Spring의 전반적인 흐름에 대해 궁금해하지 않았을까? 왜 그냥 당연하듯이 썼을까?

1주일 내내 책임과 역할에 따라 관심사를 분리하며 응집도를 높이고, 최대한 객체 지향적으로 고민하며 설계한 결과 아래와 같은 그림이 나왔다. (아직 많이 부족합니다 😂)

---

나는 “코더”였다

한 주간 시간이 어떻게 흘러가는지 몰랐다.
위와 같이 설계도도 직접 그려보고, 종립 멘토님의 세심한 리뷰를 통해 하루도 빠짐없이 내 코드를 수정하였다.
매일 오후 9시까지 제출이라는 시간제한이 마치 타임 어택처럼 느껴졌지만, 하나의 개발에 온전히 집중하며 고민 끝에 코드를 작성하고 그 리뷰를 당일에 바로 받을 수 있는 게 너무나도 설레고 재밌었던 것 같다.

 

한 주의 마지막 PR을 날리고 마지막 리뷰를 받은 후, 이 화면을 보면서 30분 동안 멍때렸었다.

“나는 2년간 실무에서 개발하면서 제대로 된 개발을 해본 적이 있었나?”
부끄럽지만 생각해보면 없었던 것 같다.

SI에서의 2년은 끊임없이 쏟아져나오는 여러 프로젝트의 겹겹이 중복된 일정을 쳐내며, 순수 개발 시간보다 일정 조정, 회의, 민원 처리 등 개발 외적인 업무로 보내는 시간이 더 많았었다.
그러니 순수 개발 시간도 부족해 야근과 주말 시간까지 사용해도 항상 일정이 촉박했고, 자연스럽게 코드를 작성할 때 많은 생각을 하지 않았던 것 같다.

“어떻게 하면 좀 더 읽기 좋은 코드가 될까? 어떻게 하면 더 객체 지향적으로 짤 수 있을까?”
솔직히 이런 고민들은 잘 못 했었던 거 같다.
어쩌면 이 글을 보면서 핑계라고 보일 수도 있을 것 같다.

맞다. 핑계라고 한다면 반박할 수는 없다. 그럼에도 불구하고 해내는 사람들도 많을 테니.
지금 생각해보면 심적인 여유가 많이 없었던 것 같기도 하다.
나는 2년간 그저 “코더”였을 뿐, 어디 가서 당당하게 2년 차 개발자라고 얘기하지 못할 것 같다.

---

“개발자”의 시작

한 주 동안 하루도 빠짐없이, 오전 10시부터 오후 9시까지 오롯이 코드숨 과정에만 집중하면서 느껴진 것이 있다.

넉넉한 시간만큼 여유롭게 이것저것 생각하면서 작성하는 코드.
그렇게 완성된 코드를 보며 “오 좀 괜찮을지도...?”라고 뿌듯해하는 내 자신.
부족한 점을 디테일하게 보완해주시는 종립님의 리뷰

지옥 같던 아침이, 요즘엔 일어나는 게 너무 설렌다.
난 현재 부족한 부분이 너무 많다. 주변에서는 일 잘하는 워커홀릭이라고 불러주지만 우물 안이라고 생각한다.

좋은 개발자는 2가지의 능력이 제일 중요하다고 생각한다.
“소통 능력”, “개발 역량”

내가 직접 말하는 게 약간 민망하긴 하지만 소통 능력은 자신 있다.
하지만 개발 역량은 아직 많이 부족하다고 생각한다. 그러므로 꾸준히 계속해서 공부할 것이다.

자 그럼 이제부터 “개발 역량”을 제대로 키워보자

---

한 주의 배운점

https://github.com/CodeSoom/spring-week1-assignment-1/pull/128

 

on Review

1. if 문을 사용할 때
    - 중괄호를 반드시 사용하자
    - 조건문에는 메서드 추출을 통해 일상어처럼 읽히도록 작성하자
    - early return을 지향하자 (else 지양, 중첩 if 지양, switch/case 지양)
2. setter를 지양하자
    - setter가 남발해있다면, 해당 변수에 담긴 데이터를 믿지 못하는 순간이 오게 된다
3. 항상 NPE를 대비하는 코드를 작성하자
    - path.equals("tasks") → "tasks".equals(path)
4. 클래스를 통해 공통 관심사(책임, 역할)를 한 곳으로 응집해야 하고, 클래스마다 관심사를 확실히 분리해주는 것이 좋다.
5. 메서드는 하나의 기능만을 매우 잘 동작하도록 작성해야 한다.
6. HTTP 응답코드에서 4xx 대와 5xx 대의 관점은, 실패 주체가 “클라이언트”이냐 “서버”이냐의 관점에서 비롯된다.
7. RFC 문서와 JLS 문서를 틈틈히 읽어보는 습관을 들여보자

 

on Error

1. jackson-databind
    - jackson 라이브러리는 기본 생성자가 없는 모델을 생성하지 못한다
2. Long  타입 비교할 때 == 주의해야 한다
    - 객체 비교는 equals()를 사용을 지향하자
    - Long 타입 비교는 -128 ~ 127까지만 ==이 정상 작동
3. switch문 내 case 문에서 선언된 지역변수는 모든 case문에서 scope가 유효하다