🎄 4주차 Christmas-Promotion 구현 및 회고

모든 회고 방식은 5F 방식으로 작성하였습니다.

 

5F는 다음과 같은 키워드에 따라 순서대로 회고를 진행합니다.

---

• Fact: 사실, 무슨 일이 있었나?
• Feeling: 느낌, 어떤 느낌이 들었나?
• Finding: 배운 점, 어떤 인사이트를 얻었나?
• Future action: 향후 행동, 앞으로 무엇을 해야 할까?
• Feedback: 피드백, 앞서 정한 향후 행동을 실천해본 뒤, 이에 대한 어떤 피드백을 받았나?

 

📊 FACT (사실), 무슨 일이 있었나?

---

네 번째 미션에서는 크리스마스 프로모션 미션을 진행하였다. 이 미션에서는 고객이 식당을 방문 날짜와 메뉴를 입력하면, 그에 맞는 다양한 할인과 이벤트를 적용하여, 어떤 메뉴를 선택하였는지, 얼마의 할인을 받았는지 등을 계산하는 형식으로 진행하였다.

 

💌 FEELING (느낌), 어떤 느낌이 들었나?

---

아쉬운 점

아무래도 마지막 미션이라는 점에 대해서 아쉬움이 남았다. 더욱이 프리코스를 직접 참여하지 못한 점이 아쉬움을 느끼게 했다. 이번 프리코스 과정은 새로운 시각을 가지게 해 주었고, 그동안 미처 보지 못했던 부분들을 인식하게 해주는 소중한 경험이었다고 생각한다. 그래서 더욱 다양한 것들을 배우고 싶은 마음이 강하게 남는 것 같다.

나에게 부족한 점과 보완해야 할 부분을 스스로 파악하고 채우는 것도 물론 중요하다고 생각한다. 하지만 이런 체험을 통해서 더 빠르고 깊이 배울 수 있는 기회가 이번이 마지막이라는 사실에 아쉬움을 느끼게 되었다.

좋았던 점

이번 과정에서 가장 만족스러운 부분은 공통 피드백을 적용해보면서 알지 못했던 부분들에 대해서 알 수 있었고 배울 수 있었다는 점이 좋았다. 이전에는 '어떤 로직이 정상적으로 작동할까?', '어떤 함수나 자료구조를 사용하면 더 효율적일까?' 등의 질문에 초점을 맞추며 공부했다. 그러나 이번 피드백을 통해 내가 그동안 공부하던 방식과 바라보는 시각을 전환할 수 있었고, 더 깊은 이해와 성장을 할 수 있는 계기가 되었다고 생각한다.

두 번째로 만족스러웠던 점은 이전 피드백을 바탕으로 구현을 시작하기 전에 개발 기능 목록 작성하고, 이를 지속적으로 수정하고 보완하면서 살아있는 문서를 만들어나가는 과정이었다.

이 과정은 나의 생각을 체계적으로 정리하고 표현하는 능력을 향상시키는 데 큰 도움이 되었다. 또한, 이를 통해 프로젝트의 틀을 세우는 데 있어 원활한 진행이 가능했으며, 그로 인해 구현에 보다 집중할 수 있었다.

 

🧑🏻‍💻 FINDING (배운 점), 어떤 인사이트를 얻었나?

---

이번 미션에서 얻은 가장 큰 인사이트 중 하나는 ‘객체를 매개변수로 전달하는 것’과 ‘객체의 메서드 반환값을 매개변수로 전달하는 것’에 대한 이해였다.

객체를 직접 매개변수로 전달하는 것은 해당 객체의 모든 데이터와 메서드에 접근할 수 있게 해 주지만, 이는 객체의 내부 구현에 대한 의존성을 높이게 된다. 이로 인해 객체의 내부 구현이 변경될 때마다 그 객체를 사용하는 다른 코드도 함께 변경해야 하는 문제가 발생할 수 있다.

반면에, 객체의 메서드 반환값을 매개변수로 전달하는 방식은 필요한 데이터만 전달하므로 의존성을 줄일 수 있다. 이 방식은 객체의 내부 구현에 대한 의존성을 낮추므로, 객체의 내부 구현이 변경되어도 해당 객체를 사용하는 다른 코드는 변경할 필요가 없다.

물론 어떤 방식이 옳거나 옳지 않다고 판단하는 것이 아닌 프로젝트의 요구사항과 유지 보수성, 가독성 등을 고려하여 결정해야 한다. 하지만 개발 원칙 중 하나인 ‘의존성 역전 원칙’에 따르면, 상위 수준의 모듈은 하위 수준의 모듈에 의존하면 안 되고, 둘 다 추상화에 의존해야 한다. 따라서 해당 원칙을 적용해서 생각해 보면, 객체의 메서드 반환값을 매개변수로 전달하는 것이 좋을 것 같다고 생각한다.

두 번째로 인상 깊었던 인사이트는 ‘디미터의 법칙’과 ‘Getter를 사용하는 대신 객체에 메시지를 보내라’는 원칙을 배우게 되었다. 이 원칙들이 바로 이러한 의존성 문제를 해결하려는 핵심적인 원리이다. ‘디미터 법칙’은 객체가 자신이 직접 조작하는 객체 외에는 알지 못하게 함으로써, 객체 간의 결합도를 낮추는 원칙이다.

반면에, ‘Getter를 사용하는 대신 객체에 메시지를 보내라’는 원칙은 객체의 상태를 묻지 말고, 행동을 요청하라는 원칙이다. 이 원칙을 따르면 객체의 내부 구현을 외부에 노출시키지 않고, 객체 간의 의존성을 낮출 수 있다는 것을 배웠다.

이런 원칙들을 통해서, 코드의 유지 보수성과 가독성을 높이는 방법에 대해서 배우게 되었다. 이는 단지 코드를 작성하는 방법뿐만 아니라, 좋은 설계를 위한 핵심적인 원칙이고, 앞으로의 개발 경험에 있어서 많은 도움이 될 거라고 생각한다.

마지막으로 인상 깊었던 인사이트는 ‘private 함수의 분리와 테스트’에 대한 부분이었다. 처음에는 가독성을 위해 private 함수를 분리하였지만, 이 과정을 적용해보면서 그 이상의 의미를 발견할 수 있었다.

private 함수는 그 자체로 테스트하긴 어렵지만, 그 함수를 사용하는 public 함수를 통해 간접적으로 테스트할 수 있음을 알게 되었다. 이는 테스트의 범위를 자연스럽게 확장하게 해 주었다.

더욱 중요한 것은, private 함수가 특정 역할을 수행하고 있을 때, 해당 역할을 분리하여 새로운 객체를 만드는 것이 테스트를 더 용이하게 만들 수 있음을 알게 되었다. 이를 통해서, 너무 많은 역할을 수행하는 함수나 객체를 의미 있는 단위로 분할하는 방법에 대해서 고민하게 되었다.

그로 인해 테스트 가능한 코드를 작성하는 것이 실제 구현에도 충분히 중요하고 ‘테스트 코드도 코드다.’ 라는 말처럼 리팩토링을 통해 개선해 나가야 한다는 것을 알게 되었다. 또한, 테스트가 가능한 코드는 결국 잘 구조화된 코드를 의미하고, 이는 코드의 가독성뿐만 아니라 유지 보수성까지 향상할 수 있다는 점을 배우게 되었다.

 

⏰ FUTURE ACTION (향후 행동), 앞으로 무엇을 해야 할까?

---

 

🙇🏻‍♂️ FEEDBACK (피드백), 앞서 정한 향후 행동 실천한 뒤, 이에 대해 어떤 피드백을 받았나?

---

 

 

[ 작성일: 2023년 11월 15일 ]