<우아한테크코스 2024 프리코스> 4주차 후기: 눈떠보니우아한형제들의엔지니어로취칙해비즈니스로직을만들고있었던것에대하여

우아한 형제들 (generated by DALL.E)

3주차를 돌아보며

3주차에서 가장 크게 와닿았던 부분이 소숫점 계산이었다.
원래는 round() 메서드를 이용하여 10을 곱하고 10을 나누어서 했었는데
toFixed() 라는 아주 좋은 메서드가 있었다. 이제 깊은 깨달음을 얻었으니 앞으로는 이걸 써야겠다.

plus+ : 이거 알았으면 숫자 제한으로 안걸리도고 10억원어치 로또를 한번에 살 수 있었을지도...
무슨 소리냐고?? 로또를 10억원어치 자동으로 돌려보았던 지난주차 보고오기

프리코스 4주차는 시작부터 폭탄이 예고되어 있었다

???: 여러분들 지금까지 프리코스 잘 즐기셨죠? 이제부터는 익스펜시브코스에요~

때는 바야흐로 수업을 듣고 있는 시간대이며, 코수타가 진행되는 시기인 목요일 오후 2시 이후...
이번 주에도 수업이 있어서 라이브로 듣지는 못했지만 커뮤니티에 뭔가 이상한 글들이 올라오기 시작했다.

???

????????????
혼란이 왔지만 어느정도는 인정할 수 있었다. 만약 어려웠더라면 3주차 때 성장하는 대신에 그대로 탭을 치며 빠져나갔을 지도 모르는 일이기 때문이다.
그 외에도 보이지 않는 객체를 상상하고 코드로 구현해야하기때문에 개발자는 상상력도 중요하다 와 같은 말들도 들을 수 있었다. 아무렴 난이도가 어려우면 또 어떠한가. 설레는 마음으로 집으로 돌아가 얼른 풀어봐야겠다는 마음가짐으로 마지막 주차 프리코스를 시작했다.

??? : 디자인 패턴같은 쓰레기는 버려라

---

뭔가 현직자가 된 느낌이네!

이메일 형식의 요구조건! 한 페이지 안에 다 담기지 않은 기능명세! 실제 기업에서 준비하는 듯한 느낌의 이벤트까지! 이 모든 것을 한번에, 일주일 안에 구현해보세요!

라고 기능명세에 적혀있지는 않았지만 기능명세의 느낌이 그런 느낌이었다.

마음이 벅차오른다..
예산 상관없는 이벤트라니..!
실제 기업에서 하는 이벤트 담당 엔지니어가 되었다니..!
비즈니스팀이라니!
개발 요청이라니!

고라니!

아무튼 요구조건이 조금 많긴 했지만 지난주 처럼 차근차근히 하나씩 정리해가면 순조롭게 해결되어나갈 것이라 믿었다.
생각보다 요구조건 정리하는 데 오랜 시간이 걸리긴 했다. 정확하게 적지 않는다면 사고가 일어날 것만 같아서 신중에 신중을 가해서 적어두고 개발을 시작했다.

---

개발 순서는 어떻게 했을까?

이번에는 다이어그램을 그리지는 않았다. 단순하게 입력값 받는 과정 2번과 이를 처리하는 과정 1번으로 매우 간단할 것으로 보였기 때문이다.
그렇게 리드미를 작성하고, 기존에 fork 해서 작성하던 코드가 아닌 코드 접근을 차단하기 위해 새로 도입된 template 방식으로 프리코스가 진행되었다.
아무튼 그래서 개발 순서는 다음과 같았다.

1. 요구조건에 있는 메세지 및 숫자 상수화
2. 입력받는 로직에 대한 기능구현 및 예외처리용 모델 생성
3. 예외처리 없이 전체 코드로직 완성 후 모듈화
4. 모듈화 이후 예외처리 및 테스트코드 작성
5. 이후 코드 가독성 개선 및 추가 모듈화, 상수화 등 리팩터링

생각보다 모듈화는 먼저 하는것이 더 중요했다. 테스트코드를 통해 단위 테스를 진행하기 위한 코드를 작성한다고 해도, 그 코드가 제대로 분리되어있지 않는다면 테스트 짜기도 힘들뿐더러 나중에 다시 작성하는 것도 다 일이기 떄문이라고 생각했다. 테스트코드가 조금 많긴 했지만 이에 대한 내용은 아래에서 다시 다루도록 하겠다.

"조금" 많아요^^

---

객체를 만드는 기준은 무엇일까? 그냥 다 함수로 분리하면 안돼?

객체를 만들고 모듈화를 야무지게 하다보니 생각났던 한가지 의문이 있었다. 그냥 다 단일 함수로 분리해버리면 안되는 걸까?

모듈화를 얼마나 어떻게 해야하는가에 대한 고민을 하다보니 생겼던 질문이었다. 물론 프리코스 기간이었기에 나 스스로 답을 찾아보고자 했고, 그 이유를 다음과 같이 설명해 보았다.

객체로 만드는 것과 함수로 다 분리하는 것은 조금씩 차이가 있다고 생각을 했고, 어떠한 규칙에 따라 이를 관리하는 방법이 달라진다.

1. 객체를 사용하는 경우: 2번의 함수들을 조합해서 특정한 모델이나 도메인을 위한 기능들의 모음을 만드는 경우
2. 함수로 잘게 쪼개는 경우: 모든 로직이 시작될만한 근본적인 로직을 작성할 때 이렇게 사용, 주로 utils에서 관리

   테스트를 상세하게 짜야 기존 코드 오류도 찾을 수 있지!

테스트를 작성하기 전까지 저는 제 코드가 완벽한줄 알았어요. 알고보니 젠가의 가장 아래 블록에 금이 가있었는데 그것도 몰랐던 것이었죠.

테스트를 상세하게 짜다보니 생각보다 기존 코드에서 놓치고 있던 처리들이 있다는 것을 발견했다. 특히 모든 코드 로직의 시작점인 근본 코드를 다루는 것이다보니 더욱 상세하게 테스트를 짜는 것이 중요했다. 그래서 테스트가 84개가 된 것일지도 모르겠다.

그렇게 테스트를 모두 작성하고 나니 예상하지 못했던 오류들을 찾아서 고쳐나갔고, 이래서 테스트가 중요하구나 라고 다시 한 번 깨달을 수 있었다.

끝나기 하루 전에 발견했던 치명적인 오류...

와 이거 그냥 넘어갔으면 지금쯤 멘탈이 가루가 되어있지 않았을까?

마치 쿠X다스와 같죠.(광고 아닙니다)

이걸 하루 전에 발견해서 얼마나 다행이었을까요. 결과를 출력하는데 정말 핵심적인 데이터를 전달하는 로직에 값이 반환되지 않았다는 것을 다 끝났다고 생각하며 앱을 가지고 놀다가 우연히 알았고, 이는 기존에 테스트에 적혀있지 않았던 내용이다보니 급히 통합 테스트쪽에 추가 케이스를 5개정도 집어넣고 많은 로그를 찍어보며 "어떻게든" 오류를 해결해서 정말 다행이었다.

어떻게 해결했지?

• 기존 코드에서는 배열 내의 값을 증가시키는 로직에 return 없이 배열에 직접 접근해서 배열 내부의 값을 직접적으로 증가시켰다.
  • 그게 실제로 자바스크립트 자체적인 기능에 있었기에 그렇게 했었지만
  • 후에 로직을 변경하다보니 이 부분이 적용되지 않는 상황이 발생하였다.
  • 그래서 값을 직접 받아서 return시켜서 상위 메서드에서 변경하는 방식으로 고쳤더니 해결되었다.

static을 사용하기 좋은 상황은 무엇일까?

static, 언제 써야 좋을까?

이전까지만 해도 다른 사람들의 코드를 보았을 때 class 안에 static을 특정 메서드 앞에 붙여서 사용하는 것으로만 보였다.
하지만 이번에 4주차 과제를 진행하면서 명확한 근거를 알 수 있었다.

• static을 붙이면 인스턴스를 초기화하지 않고 바로 불러올 수 있다.
• 이 소리는 호출 할 때마다 항상 일관적인 일을 하는 메서드라면 static을 붙여 인스턴스 초기화를 하지 않아도 된다는 소리와 같다.
• 그렇게 나는 에러만을 던지는 객체를 생성하고 static을 붙여 인스턴스 초기화 없이 사용할 수 있도록 만들었다.

---

아무래도 역대급 코드파일 수를 돌파한 것 같다

자랑한번 해보겠습니다. 저 이만큼 성장했어요!

이건 진짜 시각화해서 보여주어야 할 것 같다고 판단했고, Webstorm의 다이어그램 생성 기능을 이용해서 src 내에 존재하는 파일들을 이은 아래와 같은 다이어그램을 출력해보았다...
파일이 36개 정도 된다고 해도 이건 실로 어마어마한 규모가 아닐까 싶었다. 내가 이걸 만들었다니! 기분이 아주 웅장해지네요
행운의 77커밋과 함께하는 다이어그램을 아래에 올려두었다. 어때요? 저 많이 성장했죠?

4주차

아주 멋져요!
문득 이 다이어그램을 뽑아내는 기능을 알고나니 1~3주차 때의 코드는 어떻게 나올 지 궁금했다.
그래서 과거로 서서히 돌아가보기로 했다.

3주차 - 약 1200라인

2주차 - 약 400라인

1주차 - 약 200라인

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
많이 발전했죠? 저도 그렇게 생각해요

실시간으로 발전해간 모습을 보며 매우 뿌듯했다.
앞으로 프로젝트를 해도 프리코스 한다는 느낌으로 해야겠다. 굉장히 효과적이라 10점 만점에 10,000점 드립니다

---

자신감이 붙는 마무리

그렇게 나는 마무리까지 정말 잘 해내었다.

이제 난 무엇을 해도 잘 할 수 있을 것 같다. 프리코스도 포기하지 않고 잘 끝냈는데 무엇이 두려울까? 지금
기존에 했던 프로젝트들은 그저 코드만 작성한 느낌이었다면, 이제는 여러 방면으로 테스트하기 용이하게도 짤 수 있을 것 같고, 가장 중요하게는 "모듈화"에 대한 감을 잡은 것 같다.
현재 사용하고 있는 React, Next, Svelte같은 경우에는 객체를 사용하기보다는 주로 함수로만 작성을 해왔는데, 객체도 적절히 사용하면 될 것 같기도 하고 그렇다

인줄 알았는데 요구조건을!!!!!!! 놓쳤어!!!!!!!

그렇게 나는 마무리까지 정말 잘 해내었다. 라고 생각했다. 리뷰하면서 놓친 부분들을 찾아내기 전까지 말이다.

잘못한건 공개해두고 스스럼없이 비판하라고 배웠다. 그래서 스스로를 비판해보겠다.

1. 도대체 왜 나는 코드를 사용하고 주석처리 해둔 후 지우지 않았는가
   

2. 도대체 왜 나는 혜택 금액을 "0원"이 아니라 "없음"으로 표현했는가
   

으아악

심지어 제작과정중에서는 요구조건이 정확히 일치했었다. 결국 휴먼에러가 발생하여 이런 문제들이 일어났다는 것인데...

혹시 휴먼 디버깅은 아직 안되나요. 기능 출시된다고 들은지 23년정도 된 것 같은데

---

나에게 주는 피드백

아쉬운점이 있다면 기존에 객체를 잘 활용하지 못했다는 점이었다. 생각보다 배열을 활용하는 것이 익숙하고 더 쉽게 느껴졌다보니 대부분을 배열 로직으로 작성했던 것 같다. 이번 프리코스에서도 그랬고, 그 부분이 조금 아쉬웠다.

• 후에 코드리뷰를 일부 받아보았을 때에는 지금 이것도 잘 짠 것 같다 라고 해서 다행이었긴 하지만 뭔가 뭔가 아쉬움이 남긴 해서 적어보았다.
  • 그럼에도 약 30~40여개의 파일을 리뷰해주신 리뷰어분께 감사를 표합니다.

물론 수확도 있었다. 그만큼 객체 활용도가 더 늘었다는 점. 그동안 코딩테스트에서 애를 먹었던 부분 중 하나가 객체를 잘 활용하지 못했던 부분에 대한 것이었는데, 이 부분이 약간씩 프리코스의 순기능인가 싶었다.
기한이 주어지고, 이를 실제로 구현할 수 있도록 해보니 객체에 대한 조사도 많이 할 수 있었고, 리팩터링 과정에서 계속 뜯어보다보니 "뭔지 알고있는 것"의 다음 단계로 나아갈 수 있던 것이 좋았다.
또한 여기서 말하던 "기능 단위 커밋"을 지키려고 했지만 정확하게 이해하지 못한 것 같기도 하다. 그냥 중간중간 진행될 때마다 저장하듯이 커밋을 했는데, 아직 이 부분에 대한 피드백을 받아보지 못해서 추후에 커밋을 잘 하고 있는건지 확인해보려고 한다. 물론 정답이 없다는 것을 알지만 나름대로의 원칙을 세워두고 가고 싶었다.

---

그리고 마지막 코수타에서

???: 그리고 감기걸려서 프리코스하느라 고생하신 분도 계셨고요

? 내얘기인가 ?
프리코스 2주차부터 주구장창 감기걸린 내용을 빼두지 않고 적긴 했다. 물론 나 말고도 다른 분들도 계셨겠지만 그래도 내 얘기를 하는 것 같아서 기분이 신기했다.
아닌가 이거랑 같은 상황인가

이런 느낌인가
아무튼 그래도 기분은 신기했다

추가적으로 회고 적었던 것들을 읽으셨는데 뭔가 이 글도 읽으시지 않을까 싶다(보고있으신가요? 반갑습니다)

"1주차의 코드를 보았더니 굉장히 쓰레기같다" 라고 말해야 프리코스를 제대로 했다고 볼 수 있다고 한다

• 아 내 예전 코드 쓰레기같다
  

사실 이것도 맞는 말이며, 이전에 했던 프로젝트의 코드를 보아도 정말 그렇게 느껴져서 코드를 폐기하고 싶기도 했다
분명 객체지향으로 학습을 한 것 뿐인데 함수형으로도 어떻게 해야할 지 머릿속에 계속 그려지는 것이 신기했고, 이제는 프로젝트 할 때 더 자신감있게, 더 좋은 코드를 만들 수 있을 것이라고 생각한다.

전화데이트도 있었기에 도전 했었다

• 전화데이트 시도 실패! 다들 매크로 쓰는것이 아닌가 싶을 정도로 굉장히 빨랐다. 대부분 백엔드분들이 기회를 얻었던 것으로 기억한다.
  • 이 때 누군가가 자바스크립트가 자바보다 느려서 안된다고 했던 것 같은데..(맞는말이긴 함)
• 뭔가 전화데이트 성공했으면 어떻게 말했을 지 이미 생각해둔 부분이 있다. 아래에 테스트코드를 돌려볼까?

  PhoneDate.test.js

describe("PhoneDate 제발 테스트", () => {
  test("전화를 받으면 인사를 준비한다", () => {
      const sayHello = "안녕하세요, 저는 Json이라고 합니다."
    expect(checkIsEmpty("")).toBe(sayHello);

  });
});

방금까지는 약간 과몰입이었고, 진짜는 여기에 있다.

• 몰입을 할 수 있었고, 몰입을 통해 하고싶은 일을 해내었으며, 몰입을 통해 결과로 가는 길에 필연적으로 나타나는 시련에 대한 고통을 일시적으로 잊으며 나아갈 수 있었습니다. 처음 200줄짜리의 코드만을 작성할 수 있었던 저의 상태에서 점차 코드를 잘 짤 수 있게 해주었던 프리코스만의 특수한 시스템으로 인해 저는 많은 도움을 받았습니다. 이후에 코테인원 결과가 나오기까지 약 3~4주 정도 되는 공백기에서는 프로젝트에 여기서 배운 내용들을 적용해가며 획기적으로 코드를 더 예쁘게 만들어보려고 합니다.

• 그리고 실제로 영어이름도 Jason이긴 해요.

---

I am 더닝크루거의 꼭대기에 reach 했다

여기에 보이는 우매함의 봉우리를, 개발의 길을 걷기 시작한지 11개월만에 모두 오르는데 성공했습니다!
앞으로 있을 이 절망의 계곡에서 깨달음의 비탈길까지 가는 길을 위치에너지 보존의 법칙에 따라 에너지 소모 없이 빠르게 지나가면서 바로 지속가능성의 고원에 안착하는걸 목표로 하고있습니다.

이제 어떤 일들이 기다리고 있을까요? 분명 좋은 일들이 일어날 것이라고 믿고있습니다.
노력은 결고 배신하지 않을 것입니다. 읽어주신 여러분들 모두 감사합니다.

---

End