결론부터

왜?

쓴 것 보다 훨씬 더 많이 얻어갈 수 있었다.
그게 꼭 TDD를 하는 방법이어서가 아니라, 인맥과 인연, 그 외 같이 진행했던 스터디들까지.
내가 지불한 금액보다 미안할 정도로 훨씬 많은 것을 얻을 수 있었다.

계기

코딩의 신 아샬 채널 애청자인데
어느 날 아샬님이 코드숨을 소개하시는 영상을 봤었다.
그거 보고 처음 든 생각은
'우와... 저거 신청하면 아샬님이랑 인맥이 되는건가?' 였다... ㅋㅋㅋ

코드숨 사이트에 들어가서 신청하려고 보니 가격이 만만하진 않았다.

백엔드 개발자인 내가 리액트를 배우면 어디에 쓸 수 있으며, TDD를 배우면 어떤게 좋을지.
만만치 않은 가격인데 그만큼 얻어갈 수 있을지.
코드리뷰를 받으면 어떤게 좋을지.
그렇게 한달 반 정도 고민하다가 결국 신청했다.

당시의 직장에서 더 이상 배울만한 동료가 없는 나에게 (그런 사람들이 다 퇴사해서)
선생님이 생길 기회이기도 하고,
그런 이유에서 코드리뷰를 해준다는 점이 굉장히 끌렸다.
책에서만 보던 어떻게 하는지 전혀 감이 오지 않던 TDD를 배울 수 있는 기회라서도 좋을 것 같았다.

한 것

과제

한 주가 시작될 때 마다 아샬님이 촬영하신 온라인 강의가 하나씩 오픈되고, 과제가 1~2개씩 주어졌다.

다만, 그냥 과제만 하면 되는게 아니라 '특별한' 조건이 붙는데

과제는 전부 테스트 커버리지 100%를 달성해야 했고,
ESLint를 전부 지켜야 했으며,
E2E 테스트까지 통과해야 했다.
그리고 Pull Request를 보내서 리뷰를 받아야 했다.

리뷰를 받고 꾸준히 코드를 고쳐나가야 했다.
안그러면 통과하지 못한 것으로 간주되었다.

위 스크린샷에는 테스트를 전부 통과하여 녹색으로 체크표시가 되었지만,
커버리지, ESLint나,E2E 테스트를 통과하지 못하면 빨간색으로 X 표시가 되었다.

덕분에

• Pull Request를 통한 코드리뷰
• jest를 이용하여 테스트 코드를 작성하는 방법
• 테스트 커버리지
• ESLint
• CodeCeptJS로 E2E 테스트를 하는 방법
• Github Actions

이것들을 자연스럽게 익힐 수 있었다.
(부끄럽지만 3년차가 다 되어가도록 위에 나온것들을 단 한번도 해본적이 없었다.)

코드리뷰

과제를 수행한 코드를 Pull Request 보내서 꾸준히 리뷰를 받고 계속 개선해 나갈 수 있었다.

이런 식으로 리뷰를 받는데

그게 엄청 많.....

이렇게 다 보면서 코드리뷰 해주기 쉽지 않은데...
열심히 리뷰해주시는 윤석님, 홀맨님, 기현님께 굉장히 고마웠다.

처음엔 막 짜서 올렸던 코드가 한 주가 끝나갈 즈음엔 굉장히 많이 개선되어 있었다.
그렇게 리뷰를 받을 때 마다 내가 짜는 코드에서 버릇처럼 나오는 문제점, 개선점 들을 알아갈 수 있었고
지금은 코드숨 강의를 듣기 전 보다 굉장히 많이 좋아졌다고 느끼고 있다.

스터디

이건 커리큘럼엔 없는건데 감사하게도 스터디까지 진행해주셔서

• 자바스크립트 코딩의 기술
• 함수형 자바스크립트
• The Nature of Software Development
• 클린 애자일 (다음 주)

이렇게 참여할 수 있었다.

'스터디' 라는걸 처음 참여해보게 되었는데,
혼자 공부하는 것 보다 여럿이 같이 보다보니 내가 못본것도 볼 수 있었고,
훨씬 더 많은 것을 알 수 있었다.

스터디에 참여하며
다른 언어와 다르게 작동하는 자바스크립트를 어떻게 이해하고 써야될지 좀 더 잘 알게 되었으며,
'함수형' 이라는 패러다임을 알 수 있어서 좋았고,
가치를 빠르게 전달하는 방법에 대해서도 알 수 있어서 좋았다.

굉장히 얻은게 많은데 어떻게 글로 표현하기가 쉽지가 않다.

강의를 듣고 좋아진 것

'안전한 코드를 작성하는' 부분에서 굉장히 많이 좋아졌다고 느끼고 있다.
예전엔 코드가 오작동해서 장애가 나고, 에러한테 한 대 맞고나서야 내가 뭘 잘못했는지 알았는데,
지금은 테스트 코드를 작성하고 테스트를 수행하며 중간중간 뭔가 실수하면 즉시 알 수가 있다.

테스트 코드를 작성하는 방법을 알게 되고나서는
이걸 알기 전의 나는 코드가 내 의도대로 동작하는지 확인하기 위해서
매번 디버거를 실행시켜서 그 시점까지 가야하는 미련한 방법을 쓰고 있었구나 하는걸 알게됐다.
(디버거가 나쁘다는 의미가 아니다. 내가 미련하게 쓰고있었다.)

그 다음으로는 내가 짠 코드를 돌아보며 더 좋은 방법이 있을지 생각해보게 되었다는 것이다.
여러차례 코드리뷰를 받으며 내가 이럴 때 이렇게 작성하는 버릇이 있구나 하는걸 알게되었고,
이럴 때는 이렇게 작성하면 더 짧고 간결하고 의도도 명확하게 드러낼 수 있구나 라거나,
어거지로 짧게 쓰기 보다는 차라리 한 두줄 더 쓰더라도
더 깔끔하고 알아보기 쉽게 작성하는게 좋구나 하는 것도 알게 되었다.

강의의 제목은 '리액트' 였지만, 나는 코드를 좀 더 제대로 작성하는 방법을 배웠다고 느끼고 있다.
코드숨이 아니었으면 이런걸 내가 배울 수 있었을까 싶다.

다시 강조하지만 TDD

소프트웨어 장인이나, 클린코드 같은 책에서 테스트 코드를 작성하는게 더 시간을 절약시켜 준다는 말이 있다.
처음엔 잘 몰랐는데 이것도 몇번 득을 보고나니 정말로 시간을 절약해주는구나 하고 알게됐다.

예를들어 파일명을 잘못 지어서 이름을 바꿔야 되거나, export 하는 함수명을 바꾸게 되면 그게 굉장히 많은 곳에 여파를 미치는데
테스트 코드가 아직 어디가 안고쳐졌는지 네비게이션 역할을 해준다.
(테스트 코드를 몰랐을 땐 계속 실행시키면서 에러나는 부분을 하나 하나 찾아서 고쳤었다.)

어딘가에서 실수하면 어디서 오작동해서 이상한 값이 나오는지
예전에는 디버거를 켜서 하나하나 중단점 찍으며 확인했는데,
지금은 테스트 코드 단계에서 전부 확인이 된다.

(나만 그렇게 생각하는게 아니니까...)

협업에서도 빛을 발하는데, 공통적으로 사용하는 어느 부분이 수정됐는데
그 여파로 내가 짠 코드가 제대로 동작을 안해서 고쳐달라는 요청을 받았을 때
기존에는 console.log를 찍으면서 어디서 문제가 생겼나 한참 확인했는데,
지금은 바뀐 input 값을 확인하고 테스트 코드에 반영하면서 금방 해결할 수 있게 됐다.
겪어보니 정말로 엄청나게 시간을 절약해준다.

물론 테스트 코드를 작성하는 시간만큼 더 든다고 생각 할 수 있는데
테스트 코드를 작성하기 때문에 코드를 작성하는 시간이 더 줄어들기도 한다.
말이 이상한데 이건 해봐야 알 수 있다.

그래서 다시 결론

만약 코드숨이 어떤가 고민하며 검색하다가 들어왔다면
후회하지 않을거라고 장담할 수 있다.