본문 바로가기

Hub Development/Woowacourse

[우아한테크코스] 우테코 6기 프리코스 4주차 피드백 정리

728x90

📜 우테코 6기 프리코스 4주 차


🔹 4주 차 프리코스의 미션은 크리스마스 프로모션을 만드는 미션이었다. 미션을 진행하면서 내가 고민했던 부분과 코드 리뷰를 통해서 받았던 피드백 내용을 공유해 보고자 글을 작성했다.

 

GitHub - noxknow/java-christmas-6-noxknow: 우아한테크코스 6기 크리스마스 미션을 진행하는 저장소

우아한테크코스 6기 크리스마스 미션을 진행하는 저장소. Contribute to noxknow/java-christmas-6-noxknow development by creating an account on GitHub.

github.com

 

➡️ 4주 동안 미션을 진행하며 어느 부분부터 구현해야 하는지 항상 고민해 왔다. view를 먼저 작성했던 이유는 직관적으로 보이는 부분이기도 하고, 기능을 만든 후 콘솔로 입력에 대한 출력을 바로 확인할 수 있어서 먼저 만들곤 했다. 이번에도 평소와 같이 출력 예시의 상단부터 구현하며 콘솔로 값을 확인하고 기능이 완성된 후 테스트 코드를 작성하려고 했을 때 의문이 들었다. 나는 이미 콘솔로 값을 확인했고 혹시, 프로그램 구조의 변경이 일어난다면 지금 작성하는 테스트 코드가 의미가 있는 걸까❓ 라는 의문이었다. 하지만, 테스트 코드는 작성을 통해 결합도가 높은 부분을 개선할 수도 있고, 혹시 모를 예외 상황에 대한 확인을 할 수 있기 때문에 기능 후에 작성하는 것이 맞는데 왜 이런 의문이 드는지 생각하게 됐다.

 

 이런 의문 속에서 코수타에서 들었던 내용이 생각났다. “동작 가능한 가장 작은 버전부터 만들어봐라”, “핵심 프로그램을 먼저 만들어라” 라는 말이 생각나며 원인을 깨닫게 되었다. 그동안 해왔던 일단 만들었는데 어디에 쓰지?🤔 가 아닌 핵심 로직부터 만들며 이런 내용이 필요하니깐 추가적으로 만들어야겠다.🧐 라는 흐름의 구현 순서를 잡는 게 중요하단 사실을 알게 되었다. 테스트를 작성하더라도 테스트의 변경 보다 확장되는 경우만 신경 쓰면 되기 때문에 동작이 가능한 가장 작은 핵심 프로그램을 만드는 것이 해결 방법이라고 생각했다.

 

❗구현 순서를 깨달은 후의 변화

🔹이후, 본래 작성하던 코드에서 핵심 기능을 먼저 구현하는 방향으로 설계를 바꿨다. 메뉴를 활용하여 할인 전 총 주문 금액을 구하는 로직과 날짜와 메뉴를 활용한 할인에 대한 내용을 핵심 기능으로 잡았다. 그중 할인 전 총 주문 금액을 구하는 기능을 구현한 후 마주쳤던 문제는 이 로직이 제대로 기능을 하는지 확인해 보고 싶다였다. 하지만, 콘솔 부분을 만들지 않았기 때문에 확인 방법을 고민하다 자연스레 테스트를 해봐야겠단 생각이 들었고 테스트를 통해 할인 전 총 주문 금액이 정상적으로 반환된다는 사실을 알 수 있었다. 또 다른 장점으로 클래스 간의 결합도를 줄일 수 있다는 점이 있다. 핵심을 먼저 작성했기 때문에 다른 클래스와의 결합 없이 로직을 수행하기 때문에 결합도가 적고 테스트 코드 작성에 용이했다.

 

이번 4주차는 특이하게 Pull Request를 날리는 방식이 아닌 private으로 레포를 생성해 문제를 해결한 후 따로 제출하는 방식이였고, 제출 이후 public 레포로 변환이 가능했다.

👻 문제 해결 과정 중 고민 사항

 

printError 메서드 활용


🔹 저번 미션에서 반복문을 사용하는 Controller 내부에 UI 로직을 사용했다. 하지만, Controller 내부에 UI를 담당하는 부분이 있으면 안 되기 때문에 이번 미션에서는 OutputView printError 메서드를 구현하여 에러 메시지를 넘겨주는 방식으로 리팩토링했다.

 

🧐 4주간의 회고록


❗느낀점

 

🔹 1주 차 미션을 진행하면서는 객체지향적으로 코드를 작성하는 방법뿐만 아니라 여러 가지 고민도 해보면서 다음 미션에 적용해 보고 싶은 학습 내용을 생각했다.

 

🔹 2주 차 미션을 통해서는 코드 리뷰를 받고 생긴 피드백을 미션에 적용해 보고, 리뷰 중 생긴 고민을 해결했다. 코드 리뷰를 하면서는 더 정확한 정보를 제공하기 위해 학습하고, 그에 따라 돌아온 답변을 보며 나와는 다른 견해를 통해 미션에 접근하는 시야가 넓어졌다고 생각한다. 코드를 작성하면서도 프로그램의 구조를 지금과 같이 설계한 이유, wrapper 클래스를 사용했다면 리뷰어 분들이 wrapper 클래스를 사용한 이유를 물어봤을 때 나는 뭐라고 대답해야 할까 진짜 필요한 부분일까 와 같이 내가 작성한 부분에 대해서 확실하게 알고 넘어가야겠다는 생각을 했다.

 

🔹 3주 차에는 wrapper 클래스를 사용함으로써 객체의 응집도를 높이고, 데이터의 저장과 유효성 검사 로직을 처리하는 게 가능해졌고 domain package의 다른 클래스들은 비즈니스 로직의 역할만을 담당하면 될 것이라는 생각을 했다. 이러한 상황을 바탕으로 service package가 없는 방향으로 구현 기능 목록을 수정하게 되었고 기존의 service package에서 어려움을 겪었던 테스트 코드 작성 역시 한층 수월해진 결과를 얻게 되었다.

 

🔹 마지막 4주 차 미션에서는 구현 순서의 확립과 테스트의 순기능에 대해 알게 되었다. 어느 한 주도 빠지는 날 없이 배울 점이 있었고, 머리로만 이해하는 것이 아닌 다음 미션에 직접 적용해 봄으로써 지속적으로 발전하고 지금의 코드가 될 수 있었다고 생각한다.