본문 바로가기

우아한 테크코스 5기

[우아한 테크코스] 레벨 1 - 사다리 미션 회고

우테코에서의 두 번째 미션은 사다리 만들기!!!

저번과 마찬가지로 아래는 미션을 진행한 repository와 PR 목록들입니다.

 

사다리 게임 repository

 

GitHub - Ohjintaek/java-ladder: 사다리타기 미션을 위한 저장소

사다리타기 미션을 위한 저장소. Contribute to Ohjintaek/java-ladder development by creating an account on GitHub.

github.com

1차 PR

 

[1단계 - 사다리 생성] 썬샷(오진택) 미션 제출합니다. by Ohjintaek · Pull Request #67 · woowacourse/java-ladd

안녕하세요 영이. 우테코 5기 썬샷입니다. 리뷰 맡아주셔서 감사드립니다. 이번 미션 1단계 때에는 TDD를 처음 경험해보는 것과 기능 요구사항에 충실하는 것을 중점으로 페어프로그래밍해보았

github.com

2차 PR

 

[2단계 - 사다리 생성] 썬샷(오진택) 미션 제출합니다. by Ohjintaek · Pull Request #198 · woowacourse/java-lad

안녕하세요 영이!! 2단계 미션도 리뷰 잘 부탁드립니다. 2단계에서 요구하는 기능들을 작성하기 이전에 1단계에서 lineGenerator에서 너무 많은 역할을 하고 있기 때문에 분리하는 것이 좋겠다는 피

github.com

 

 

🤪 무엇을 했지?

사다리 미션
  • 미션 내용을 간단히 설명하면 사다리 게임을 구현하는 것이다. 1단계에서는 참여할 사람 수와 생성할 사다리의 높이를 입려기받으면 무작위로 사다리를 출력해주면 되고 2단계에서는 사다리 게임의 결과까지 구현하는 것이 목표!! 우테코의 미션이 항상 그렇듯 1단계는 페어프로그래밍으로 진행된다.
  • 새롭게 만난 페어 홍실과 함께 미션을 진행했다. 첫 페어프로그래밍 때 사용했던 방식인 일정한 시간마다 역할을 바꾸는 것이 좋았어서 해당 방식을 제안했다. 서로 동의해서 20분마다 역할을 바꾸고 서로 2번씩 역할을 바꾸었다면 10분간 휴식하는 걸로 진행했다. 근데 막상 시작해보니까 미션에 너무 몰입해서 그런가 20분이 너무 짧게 느껴져서 '시간이 너무 빨리 간다'고 얘기했던 기억이 난다. 😁😁
TDD
  • 이번 미션이 자동차 경주 때와 가장 달라졌다고 느낀 점은 TDD로 진행해야 한다는 것이다. TDD는 Test-Driven Development (테스트 주도 개발)의 줄임말로 구현해야 할 기능이 있다면 해당 기능에 대한 프로덕션 코드를 먼저 작성하는 것이 아닌 테스트 코드를 먼저 구현한 뒤 작성한 테스트를 통과하도록 프로덕션 코드를 작성하는 방식으로 프로그램을 구현해나가는 방식이다. (참조)
  • 우테코 강의 때 들었던 표현을 빌리자면 TDD는 불안함을 불편함으로 바꾸는 방법이다. 실제 프로덕션 코드를 작성하기 전에 테스트를 작성하는 과정은 머리가 아프고 매우 귀찮지만 작은 단위부터 차곡차곡 쌓아올린 테스트 코드들을 통해 작성된 프로덕션 코드는 믿을 수 있는 코드가 된다. 페어와 최대한 TDD를 지키면서 미션을 진행하는 것을 목표로 삼고 시작했지만 제대로 지키지 못했는지 코드 리뷰 때 테스트 코드가 부실하다는 코멘트를 받았다. TDD 어렵다... 😥
Controller와 Service
  • 저번 미션에 이어 이번에 새롭게 접하게 된 개념이다. MVC 패턴으로 구현하는 것은 프리코스 과정 때부터 해서 Controller라는 계층이 있다는 것은 들어봤지만 또 Service라는 계층이 존재한다. (Repository도 있다) Controller는 View와 Domain을 연결해주는 역할을 하는데 이 때 서로 넘어가는 정보들에 별다른 처리를 할 필요가 없다면 그대로 넘겨주면 되지만 View나 Domain에서 요구하고 반환하는 데이터 형식이 달라 별도의 처리를 해 주어야 할 가능성이 높다. 이런 처리들을 포함해서 Controller에서 프로덕션 코드를 다루기 위해선 별다른 로직이 필요하기 때문에 따로 Service 계층을 만들어 그 책임을 넘겨줄 수 있다.
  • 자동차 경주 미션에 비해 미션이 조금 더 복잡해져서 Controller의 크기가 커지니 페어가 분리해야 할 필요성을 느꼈는지 얘기를 꺼내게 되어서 알게 되었다. 처음 개념을 듣고 생각해봤을 때 '정말 유용한 역할을 하는 애구나' 싶었다. 하지만 1단계를 진행할 당시에 Service 계층을 추가해주더라도 Service 객체 하나, Controller 객체 하나만 만들어지고 Controller 내부에서 분리될 기능들이 적다고 생각해서 스스로는 큰 필요성을 느끼지는 못 했다. 페어 프로그래밍 중 수정하고 싶은 내용이 있다면 상대방을 확실하게 설득시켜야 하는데 나 스스로 납득이 되지 않아 원래 구현했던 대로 진행하기로 했다. 2단계 미션을 혼자 진행하면서도 Service 계층이 필요할 것인가에 대해 고민해봤었는데 현재 미션의 사이즈에서는 굳이 분리할 필요가 없다는 생각이 그대로 유지되긴 했다. ( 미션들을 계속 진행하면서 느끼는 거지만 구현해야 할 프로그램의 규모에 따라 프로그래밍 할 때 달라지는 게 상당히 많다는 생각이 든다.)
assertDoesNotThrow()의 위험성
  • 객체가 제대로 생성되었는지 확인하기 위한 테스트 코드들에서는 생성자를 통해 개게를 생성했을 때 예외가 발생하지 않으면 제대로 생성되었다는 의미로 assertDoesNotThrow()를 주로 사용했었다. 하지만 이번에 코드리뷰를 받을 때 리뷰어였던 영이가 해당 메서드를 사용하는 것을 별로 좋아하지 않는다고 코멘트를 남겨주었다. 예를 들면 Ladder라는 객체는 파라미터로 숫자를 받아서 생성되는데 높이가 5라는 사다리를 만들기 위해 new Ladder(5); 라는 생성자를 호출한다. 이 때 예외가 발생하지 않더라도 실제 5의 높이를 가지는 사다리가 생성되었는지는 알 수가 없기 때문에 제대로 된 검증이라고 할 수가 없다. 따라서 객체르 생성해준 뒤 직접 내부의 값을 확인할 필요가 있다고 했고 이에 굉장히 공감하여 수정을 해 주었다. 내부의 값에 접근할 수 있는 메서드가 있다면 사용해주거나 extracting을 사용해주는 방법 등이 있을 수 있다.

 

코드를 짤 때는 항상 생각을 해야 한다

 

 

 

👍 좋았던 점

미션에 대한 기록
  • 페어 프로그래밍하면서 여러 고민들을 나누었는데 홍실이 해당 사항들을 하나하나 Notion에 기록했고 그 페이지를 공유까지 해 주었다. 평소 기록의 필요성은 인식하고 있지만 책을 읽고 정리하거나 시험 공부를 위해 필기하는 경우가 아니면 기록을 해본 적이 거의 없었는데 항상 어떤 일이 있었는지 제대로 기억을 하지 못하는 경우가 빈번했다. 인간은 망각의 동물, 망각은 사실 축복이다와 같은 말들을 떠올리며 애써 기록과 멀리하는 삶을 살았지만 우테코에서는 그러지 않아야겠다는 생각을 하게 된 것이 이번 경험 때문이었다. 사실 사다리 미션이 끝난지 3주가 지났음에도 이렇게 상당한 양의 글을 쓸 수 있는 것이 다 기록 덕분이기에 좀 더 의식적으로 기록하는 습관을 가져야겠다.

 

 

🤔 아쉬웠던 점

미숙한 테스트 코드 작성
  • 1단계에 대해 영이가 해준 코드 리뷰의 대부분은 사실 테스트코드에 관한 것이었다. 특히 이번 미션이 TDD로 진행하는 첫 번째 미션이었기 때문에 최대한 TDD로 진행해보려고 생각했었고 리뷰어도 그 부분을 집중적으로 봐 주었는데 제대로 하지 못 했다 ㅎㅎ. 리뷰어는 해당 부분에 대해서 먼저 도메인의 역할에 대해 고민해보고 test를 작성해보면 좋을 것 같다는 조언을 주었다. TDD 수업 때 네오가 구현해야 할 기능들을 작성한 뒤 가장 작다고 생각되는 기능들부터 테스트 코드를 작성해나갔고 그에 따라 필요한 객체들을 생성해나가는 것을 보여주었는데 이 방식은 좀 더 내공이 쌓여야 할 것 같다. 이후 미션들에선 도메인들을 먼저 간략하게 생각을 하고 진행하니 좀 더 TDD스럽게 작성하는 게 수월해졌다.
설계를 갈아엎는 것에 대한 두려움
  • 페어 프로그래밍 때 Service를 도입하는 것에 대해 얘기를 나누면서 나름의 근거와 내가 생각하는 것에 대해서 얘기를 해서 결국 도입하지 않는 것으로 결론이 나긴 했지만 사실 연습 삼아 Service 계층을 구현해볼 수도 있을 것이다. 다른 크루들을 보면 설계를 아예 처음부터 갈아엎는다거나 처음부터 다시 구현한다는 얘기들도 심심찮게 들리는데 나는 아직 잘 돌아가는 코드를 갈아엎는 것에 대해 두려움이 크다. 경험이 부족한 것에서 오는 두려움인지 처음 작성한 코드에 대한 믿음이 강해서인지 잘 모르겠지만 학습 초기인 지금, 아무것도 모를 때 이것저것 해 보는 게 더 좋을 것이라는 생각을 해 본다.

 

 

😎 기술적 발전

  • Service 계층의 의미와 언제 사용하는지
  • assertDoesNotThrow()의 위험성
  • stream 사용 (아직 미숙)

 

 

 

🏃‍♂️ 소감 / 앞으로의 계획

  • 회고를 쓰고 있는데 쓰는 시점이 미션이 끝난 뒤 3주가 지난 시점이라 감정적으로 끝날 때 어떤 느낌이었는지, 내가 미션이 최종 merge되고 난 뒤에 어떤 생각을 했었는지 알 길이 없다. 미션 진행하면서 어떤 어려움이 있었는지, 무슨 얘기를 했는지, 무엇에 대해 논의를 했는지는 위에 언급한 기록을 통해 어떻게든 작성할 수 있는데 감정은 쉽게 휘발되기에 회고 같은 건 정말 바로 적어주어야겠다. 당장 다음 미션인 블랙잭도 끝났지만 아직 작성하지 않았기에 이 파트는 여기까지 적는 걸로...