우아한테크코스 7기 프리코스 4주 차 회고

벌써 마지막 4주 차 미션의 마지막 날이다.
3주 차 미션 제출 후 마지막 커밋 때 테스트를 한 번 안 돌려본 것에 큰 충격을 받아 이번 미션에서는 절대 같은 실수는 하지 않겠다고 다짐했다.
그래서 1~3주 차 미션 때와 다르게 '돌아가는 쓰레기'를 만들기보다 TDD에 우선순위를 두고 미션을 시작했다.
스스로 테스트 코드의 중요성을 좀 깨달아보자고 생각하면서🤣

이번 회고에서도 주어진 질문에 먼저 답변해 보려고 한다.

 

지원서나 중간 회고에서 현실적인 목표를 설정하고 이를 달성했다고 생각하나요? 그 이유는 무엇인가요?

지원서에서 설정했던 목표를 중간 회고에서 변경하지 않아도 된다고 했었다.

• 건강하게 개발하기
• 숲과 나무를 모두 보기

두 가지 목표였는데, 2주 차가 마무리됐던 중간 회고 때엔 목표를 잘 달성했다고 생각했다.
4주 차가 마무리된 지금은 오히려 목표 달성률이 조금은 떨어지지 않나 생각된다.

2주 차와 마찬가지로 건강하게 개발하기는 기준점인 '최소 주 3회 8000보 이상 걷기'를 만족했기 때문에 100% 달성했고, 오히려 초과 달성하기도 했다!
날이 곧 많이 추워질 텐데 따뜻한 가을볕을 즐기려면 조금 더 자주 많이 걸어야겠다.

다만 숲과 나무를 모두 보기 목표는 일부 달성한 것도 있고 달성하지 못한 것도 있는 것 같다.
3주 차에서의 실수 때문인 것도 있지만, 제공되었던 요구 사항들을 모두 꼼꼼하게 확인하며 진행했다고 생각했는데 그렇지 않았던 경우도 있었기 때문이다.
불용어인 data를 쓰지 않아야 하는데 썼다거나.. 메서드 라인이 15라인, 10라인을 넘지 않도록 해야 하는데 넘었다거나..

이 경험으로 다시 한번 자만하지 않고 더 꼼꼼히 살펴야겠다고 생각했다.

 

중간 회고에서 조정한 목표가 실제 목표 달성에 도움이 되었나요? 목표를 달성하는 데 어떤 점이 효과적이었다고 생각하나요?

중간 회고에서 목표를 조정하지 않았는데, 목표를 조정하지 않고도 실제 목표 달성에는 도움이 된 것 같다.
그 목표 그대로 이어갔기 때문에 목표 달성에 내가 부족한 것이 무엇이었는지, 놓친 것이 무엇인지 알 수 있었기 때문이다.

특히 건강하게 개발하기와 같은 목표는 단순히 운동하기!라고 목표를 정했을 때보다 구체적인 수치화를 하며 목표를 정하니 목표를 달성하는 데 더 효과적이었다고 생각한다.
게다가, '손목 닥터 9988+' 라는 어플로 걸음 수를 통해 서울페이도 벌어들일 수 있어서 더 좋았다!

그리고 목표를 조정하지 않았기 때문에 목표들을 매일 더 자세히 되새기면서 부족했던 점도 알 수 있었다.

 

각 미션의 목표를 달성하기 위해 세운 계획을 잘 이행했나요? 그 과정에서 어떤 전략이 효과가 있었나요?

매회 차 미션마다 코드를 짜기 전에 나만의 README 템플릿을 만들어 프로그램 실행 순서, 기능 목록, 테스트 목록을 기록하기로 했었는데, 이 계획이 미션의 길을 잡아주는 데 도움이 되어 참 좋았다.
처음 미션을 받아 읽어 보고 나면 항상 머릿속에 떠오르는 수많은 생각들을 정리하기가 어려웠는데, 나만의 README 템플릿을 작성하면서 머릿속이 정리되기도 하고, 프로그램의 흐름도 정리할 수 있어서 좋았다.
물론 초안으로 작성한 README는 프로그램 구현이 진행되면서 계속 바뀌기도 했지만, 처음의 많은 생각들을 정리하는 데에 큰 도움이 되었다고 생각한다.

그리고, 이 미션으로 내가 어떻게 성장할 수 있을지, 우테코에서 이 미션들을 통해 내게 알려주려고 하는 것들이 무엇일지 계속 고민하며 미션을 진행한 것도 효과가 있었다.
특히 4주 차 미션이 많이 어려워서 '왜 이렇게 어려운 미션을 준 거지?', '너무 어려운데!'라는 생각만 가득했었는데, 이런 생각이 들 때마다 잠시 머리를 식히고 오면 '이 미션을 통해 어떤 걸 얻을 수 있지?'라고 생각이 전환되고 해결되지 않던 문제들도 해결할 수 있었다.

 

몰입하고 함께 성장하는 과정을 통해 인상 깊었던 경험이나 변화가 있었나요?

코드 리뷰! 내가 짠 코드를 누군가에게 보여준다는 것이 쉽지 않았는데, 많은 사람과 코드 리뷰를 하면서 다양한 의견을 많이 접할 수 있었다.
특히 같은 미션이어도 다르게 해석될 수 있다는 것, 다르게 해석한 사람들과 의견을 나누면서 내가 맞고 당신이 틀린 거야 라는 이분법적 사고가 아니라 '다른' 생각을 나누는 것이 코드 리뷰를 하면서 인상 깊었던 경험이다.
내가 생각하지 못했던 다른 생각들로 견문을 넓히는 느낌! 좋았다.

처음 프리코스를 시작할 때만 해도 '코드 리뷰.. 내가 잘할 수 있을까? 다른 사람들이 내 코드를 보고 웃지 않을까?' 부끄러운 마음뿐이었는데, 개발자는 소프트 스킬도 중요하다는 것을 다시 한번 느끼게 해 준 경험이었다.
그리고 코드 리뷰를 원한다면 타인이 먼저 해주길 바라기보다, 내가 먼저 상대의 코드를 읽고 의견을 전한 뒤 리뷰를 하러 와주길 기다리는 것이 더 마음이 편하다고 생각했다.

 

상수 처리의 기준

매직 넘버를 모두 상수 처리해야 하는가? 라는 의문을 항상 가지고 있었는데, 이 역시도 입력 검증 기준처럼 나만의 기준을 만들었다.

• 한 번만 사용되는 매직 넘버는 굳이 상수 처리하지 않기
• 매직 넘버 그 자체로 가독성이 명확하다면 상수 처리하지 않기
• 클래스 내부에서 반복적으로 사용되는 매직 넘버는 상수 처리하기
• 연관성이나 확장 가능성이 있거나 내부에서 상수를 통해 비즈니스 로직이 이루어진다면 Enum으로 상수 처리하기

이러한 기준을 세우고 나니 상수 처리를 하는 데에 고민하는 시간이 조금 줄어들었다.
특히, 예외를 커스텀 클래스로 분리하고 나서 예외 메시지들을 상수 클래스로 관리했었는데, 생각해 보니 에러 코드가 필요하다거나, 확장될 가능성이 충분히 있다고 생각하여 이번 주 차에서는 Enum으로 관리하게 되었다.

 

커스텀 예외

3주 차에 커스텀 예외를 도입하고, 다양한 예외 상황들을 생각해볼 수도 있어서 좋았었다.
그래서 4주 차에도 커스텀 예외를 만들었고, 이번에는 커스텀 예외를 더 다양하게 활용해보려고 했다.
https://velog.io/@carol_ly/잘-만든-커스텀-예외
프리코스 커뮤니티에 올라온 위 글이 다양한 인사이트를 얻게 해주었다.
개발자가 생각한 예외뿐만 아니라 다른 예외도 잘 고려해야겠다고 생각했다.

다음에 프로젝트할 때도 꼭 도입해 봐야지!

 

getter 지양하기

이번 4주 차에 가장 어려웠던 점이자 아쉬운 점이 아닌가 싶다.
객체 지향 언어를 공부하면서 객체를 객체답게 사용하기 위해 getter 사용을 지양해야 하는데 파일로부터 불러온 Product 객체와 Promotion 객체를 Order 객체에서 활용하려다 보니 어쩔 수 없이 getter를 사용하게 되었다.

하지만 Product와 Promotion의 정보를 함께 알고 있는 Order 객체가 수행하려는 일을 위해서이니 괜찮지 않을까..라는 생각도 해본다.
어서 다른 사람들의 코드도 보고, 어떻게 하면 더 객체 지향스러운 코드로 작성할 수 있을지 궁금하다.

 

주어진 기능의 실행 결과 예시의 반례 생각하기

TDD를 통해 기본 테스트를 통과하는 최소한의 기능 구현을 진행하고 리팩토링을 하면서 버그를 알게 되었다.
물론, 처음부터 모든 버그를 알고 해결할 수 없겠지만 주어진 기능의 실행 결과 예시를 보고 반례를 생각하는 것이 버그를 고치는 데에 더 도움이 된다는 것을 깨달았다.

주어진 기능의 실행 결과 예시는 많은 경우의 수를 포함하고 있는데, 그 경우의 수를 모두 해결하려고 하기보다는 정확히 반대되는 반례만 생각해 보더라도 문제 해결이 훨씬 빨라진다고 생각했다.

이번 주 차의 내용을 예시로 들어 보자면,
- 프로모션 할인이 적용되지 않는 상품 개수를 안내했을 때, 구매하겠다고 하면 프로모션 할인을 적용하여 결제한다.
-> 반례 : 구매하지 않겠다고 하면 프로모션 할인이 적용되는 상품만 결제하도록 안내한다.

- 무료 증정 가능한 상품과 개수를 안내했을 때, 받겠다고 하면 영수증에 함께 포함하여 출력한다.
-> 반례 : 받지 않겠다고 하면 기존 구매 요청 상품 개수만 결제하도록 하고, 영수증에 포함하지 않고 출력한다.

두 가지의 경우가 반례를 생각했을 때 버그 해결에 많은 도움이 되었다.

 

DTO의 사용

꼭 사용해야 하는 이유를 모르겠어서 DTO를 사용하지 않았었는데, 이번 주에는 사용자 입출력을 담당하는 클래스를 분리하라는 요구 사항이 있었다.
해당 요구 사항은 1주 차부터 항상 지키고 있었지만, 이번 프로그램의 기능을 구현하다 보니 자연스럽게 DTO 사용을 할 수밖에 없었다.

프로그램의 진행 순서가 계속 사용자와의 소통을 토대로 이루어졌기 때문이다.

• 파일 입출력으로 상품 목록 안내
• 구매할 상품 입력받기
• 프로모션 할인 중인 상품이 포함되어 있지만 재고 부족으로 적용되지 않는 개수를 안내하고 그래도 구매할 것인지 입력받기
• 입력에 따라 재고 처리
• 프로모션 할인 중인 상품이 포함되어 있고, 추가로 받을 상품이 있다면 받을지 입력받기
• 입력에 따라 재고 처리
• 재구매할 것인지 입력받기

비즈니스 로직이 사용자와의 소통에 따라 계속 달라졌기 때문에, 사용자 뷰에서 보여줄 정보는 DTO를 통해서 담는 것이 좋겠다고 생각했다.
과정이 조금 더 복잡해지긴 했지만, 이유를 깨닫고 사용하니 훨씬 더 좋았다.

 

테스트의 아쉬움

구현 초기에는 최대한 TDD를 시도하려고 노력했다. 사용자 입력과 데이터 접근, 매핑하여 객체를 생성하는 부분까지는 TDD로 구현했는데, 여러 기능이 얽혀 있는 재고 관리, 프로모션 할인, 멤버십 할인부터는 TDD를 적용하지 못해 아쉽다.

사실 이때부터 기능 구현에 혼란이 와서 우선 기본 테스트를 통과하도록 구현했고, 리팩토링 하는 데에 시간을 많이 할애하느라 추가로 더 테스트를 만들지 못한 점이 제일 아쉽다.
미션 코드 제출 시에는 제출하지 못하겠지만, 이후에 테스트 코드를 만들어서 추가해 두도록 해야겠다.

 

예제 테스트 결과 4/4 통과 완료! 이번에는 마지막 푸쉬 전에 테스트 돌려보고 예제 테스트 실행도 다시 한 번 더 해봤다!!!

프리코스의 4주 차 마지막 최종 회고라는 것이 믿기지 않는다.
매주 새로운 미션을 받고 해결하기 위해 오랜 시간 고민하고, 인텔리제이에게 왜 안 돼!! 소통하던 시간들이 즐거웠다.
3주 차에 큰 실수가 있었지만, 스스로 만족할 만큼 공부도 열심히 했고, 모든 미션에 최선을 다했다.
후회 없이 최선을 다 했으니, 좋은 결과로 이어지면 좋겠다! Happy coding!🚀

 

귀여운 지피티

 

사실 실수한 거 아쉽고 이번 주도 스파게티 코드에 아쉬운 거 투성이라 우테코 더 하고 싶다..😭

 

4주 차 프리코스 코드 레포지토리 :

https://github.com/ljhee92/java-convenience-store-7-ljhee92

12일 00시 이후 퍼블릭 변환하여 공개 예정! (private -> public 돌려서 공개 가능하다고 함!)

설계 미스가 있는 코드라는 걸 깨닫긴 했지만.. 그래도 공개!