며칠 전, 카카오의 역대급 오류로 인해 많은 불편함을 겪었다.
평소에 티스토리를 통해 블로그를 작성하였지만, 정상화가 너무 오래 걸리는 것 같다.
고민 끝에 velog로 넘어오기로 결심했다.
기존 티스토리 글은 차차 옮겨 올 예정이다
앞으로 velog에서는 직접 개발을 통한 문제점, 깨달음 등을 진솔하게 적어볼까 한다.
자 그럼 첫 번째 글은 최근에 시작한 코드숨이라는 멘토링을 주제로 꾸준한 기록의 시작을 해볼까 한다.
"오히려 좋아”
나는 최근 퇴사를 하고 집 근처 공유 오피스에서 나와 같은 이직을 준비하는 개발자 3명과 함께 4인실을 사용하며, 최소 주 6일을 계속해서 공부하고 있었다.
이제껏 입에 달고 살았던 “아… 코드 리뷰 받아보고 싶다”라는 말을 어김없이 공유 오피스에서도 하다가, 문득 스터디원 한 명이 코드숨을 추천해주었다.
“떠먹여 주는 식이 아니라, 하는 만큼 얻어가는 멘토링”이라며 본인은 굉장히 만족했다고 했다.
적지 않은 비용이었지만, 굉장히 매력적으로 다가왔고 “오히려 좋아”를 외치며 바로 결제를 해버렸다.
“개발”의 시작
2022년 10월 10일 월요일, 회사를 계속 다니고 있었다면 꿀 같은 연휴를 만끽하고 있을 대체 공휴일에 코드숨이 시작되었다.
8주간 코드 리뷰를 받으며 Test Code와 JPA까지 배우는 과정이라 매우 기대하며 강의를 듣기 시작했다.
추천해준 지인이 말했듯이 떠먹여 주는 식이 아니라, “인출 중심”의 교육답게 일정 부분만 알려주고 나머지는 과제로 해오는 미션을 받았다.
1주차는 Java만을 이용하여 간단한 API CRUD를 구현하는 미션이다.
실무를 할 때 공장처럼 질리도록 만들어봤으니 자신 있게 시작했다.
“엥….?”
웬걸, 익숙한 Spring 없이 생판 처음부터 짜려고 하니까 머릿속이 하얘졌다.
그날 작업한 부분을 오후 9시까지 PR을 날려야 리뷰를 받을 수 있기에 부랴부랴 기능 구현 중심으로 코드를 작성했다.
그리고 떨리는 마음으로 첫 번째 PR을 날렸다.
리뷰어님은 평소에 이미 여러 지인분들을 통해 듣기도 하고, 구글링하면서도 몇 번 블로그에서 본 기계 인간 이종립님이셨다.
무척 영광이기도 하고 내적 반가움도 있고, 여러 복잡한 감정을 갖고 달아주신 리뷰를 보기 시작했다.
기능 구현에만 집중하다 보니 이건 뭐, 내가 봐도 읽을 수 있는 메서드가 아니었다.
이뿐만이 아니었다. 리뷰를 계속해서 읽어 내려가다 보니, 인지하고 있었지만 “구현 먼저 빠르게 하고 리팩토링하자”라고 넘어갔던 부분들을 제외하고도 미처 생각하지 못한 것들을 아주 많이 찾아주셨다.
다음날부터는 계속해서 리팩토링을 중심으로 코드를 작성했다.
1주차는 Spring 없이 순수 Java로 API를 만드는 것이라 처음부터 신경 쓸 게 너무 많았다.
한편으로는 평소에 Spring이 지원해주는 편한 기능들을 아무 생각 없이 사용했다는 것이 많이 느껴졌다.
왜 이제껏 Spring의 전반적인 흐름에 대해 궁금해하지 않았을까? 왜 그냥 당연하듯이 썼을까?
1주일 내내 책임과 역할에 따라 관심사를 분리하며 응집도를 높이고, 최대한 객체 지향적으로 고민하며 설계한 결과 아래와 같은 그림이 나오더라. (아직 많이 부족하다)
나는 “코더”였다
한 주간 시간이 어떻게 흘러가는지 몰랐다.
위와 같이 설계도도 직접 그려보고, 종립 멘토님의 세심한 리뷰를 통해 하루도 빠짐없이 내 코드를 수정하였다.
매일 오후 9시까지 제출이라는 시간제한이 마치 타임 어택처럼 느껴졌지만, 하나의 개발에 온전히 집중하며 고민 끝에 코드를 작성하고 그 리뷰를 당일에 바로 받을 수 있는 게 너무나도 설레고 재밌었던 것 같다.
한 주의 마지막 PR을 날리고 마지막 리뷰를 받은 후, 이 화면을 보면서 30분 동안 멍때렸었다.
“나는 2년간 실무에서 개발하면서 제대로 된 개발을 해본 적이 있었나?”
생각해보면 없었던 것 같다.
실무에서의 2년은 끊임없이 쏟아져나오는 여러 프로젝트의 겹겹이 중복된 일정을 쳐내며, 순수 개발 시간보다 일정 조정, 회의, 민원 처리 등 개발 외적인 시간이 더 많았었다.
그럼으로써 자연스럽게 절대적인 시간이 부족해서 야근과 주말 출근을 하면서도 일정이 촉박해, 코드를 작성할 때 많은 생각을 하지 않았던 것 같다.
“어떻게 하면 좀 더 읽기 좋은 코드가 될까? 어떻게 하면 더 객체 지향적으로 짤 수 있을까?”
솔직히 이런 고민들은 잘 못 했었던 거 같다.
어쩌면 이 글을 보면서 핑계라고 보일 수도 있을 것 같다.
맞다. 핑계라고 한다면 반박할 수는 없다. 그럼에도 불구하고 해내는 사람들도 많을 테니.
지금 생각해보면 심적인 여유가 많이 없었던 것 같기도 하다.
나는 2년간 그저 “코더”였을 뿐, 어디 가서 당당하게 2년 차 개발자라고 얘기하지 못할 것 같다.
“개발자”의 시작
한 주 동안 하루도 빠짐없이, 오전 10시부터 오후 9시까지 오롯이 코드숨 과정에만 집중하면서 느껴졌다.
넉넉한 시간만큼 여유롭게 이것저것 생각하면서 작성하는 코드.
그렇게 완성된 코드를 보며 “오 좀 괜찮을지도...?”라고 뿌듯해하는 내 자신.
부족한 점을 디테일하게 보완해주시는 종립님의 리뷰
지옥 같던 아침이, 요즘엔 일어나는 게 너무 설렌다.
난 현재 부족한 부분이 너무 많다. 주변에서는 일 잘한다고 해주지만 우물 안이라고 생각한다.
좋은 개발자는 2가지의 능력이 제일 중요하다고 생각한다.
“소통 능력”, “개발 역량”
내가 직접 말하는 게 약간 민망하긴 하지만 소통 능력은 자신 있다.
하지만 개발 역량은 많이 부족하다고 생각한다. 그러므로 꾸준히 계속해서 공부할 것이다.
자 그럼 이제부터 “개발 역량”을 제대로 키워보자
한 주의 배운점
https://github.com/CodeSoom/spring-week1-assignment-1/pull/128
on Review
- if 문을 사용할 때
- 중괄호를 반드시 사용하자
- 조건문에는 메서드를 통해 일상어처럼 읽히도록 작성하자
- early return을 지향하자 (else 지양, 중첩 if 지양, switch/case 지양)
- setter를 지양하자
- setter가 남발해있다면, 해당 데이터는 믿지 못하는 순간이 오게 된다
- 항상 NPE를 대비하는 코드를 작성하자
path.equals("tasks")→"tasks".equals(path)
- 클래스를 통해 공통 관심사(책임, 역할)를 한 곳으로 응집해야 하고, 클래스마다 관심사를 확실히 분리해주는 것이 좋다.
메서드는 하나의 기능만을 매우 잘 동작하도록 작성해야 한다. - HTTP 응답코드에서 4xx 대와 5xx 대의 관점은, 실패 주체가 “클라이언트”이냐 “서버”이냐의 관점에서 비롯된다.
- RFC 문서와 JLS 문서를 틈틈히 읽어보는 습관을 들여보자
on Error
- jackson-databind
- jackson 라이브러리는 기본 생성자가 없는 모델을 생성하지 못한다
- Long 타입 비교할 때 == 주의해야 한다
- 객체 비교는 equals()를 사용을 지향하자
- Long타입 비교는 -128 ~ 127까지만 ==이 정상 작동
- switch문 내 case 문에서 선언된 지역변수는 모든 case문에서 scope가 유효하다
