우아한테크코스 level 1-2 Lotto 미션 회고 및 학습 프로필
Level 1-2 : Lotto
페어 코딩을 하다보면 상대방과 내가 서로 정확하게 인지 못하는 기능 구현 부분들을 자주 맞닥드린다. 그럴 경우 나는 한 발 물러서서 수용하는 자세로 페어 코딩에 임한다. 그러다보니 남들이 하는 것을 따라 하려고만 하고 정확하게 해당 구현 방식이 의미하는 컨벤션, 기능 구현을 이해하지 못한채로 구현에 임했었다. 그렇게 구현을 끝마치고 리뷰를 받다보니 아니다 다를까 서로 확신이 서지 않던 부분은 대부분 지적을 당하는 것을 볼 수 있었다. 🤣
하지만 우아한 테크 코스에서는 이러한 잘못된 개념을 바로잡는 리뷰어 분들이 계시기에 오히려 올바르지 못한 코드를 구현하고 리뷰를 받는 것이 저는 기쁘게 느껴진다. ‘틀린 후 올바르게 고친 문제는 오랫동안 기억에 남는다.’ 내가 항상 공부할 때 생각하는 문구이다. 애매하게 알고있는 지식을 다시 학습해서 공부하는 것보다 일단 틀리고 해답에 대한 힌트를 토대로 학습하는 방식은 기억에 오래 각인되기 때문에 너무 좋다. 😍
다른 곳에서는 틀리면 그에 준하는 댓가가 따르기 마련이다. 하지만 우아한 테크 코스 교육 과정에서는 그렇지 않다. 경쟁 구도에서만 학습을 하다보니 자꾸 망각하게 되는 것 같다. 함께하는 크루들의 지식의 정도는 다르다. 그들은 조금 더 앞에 배울 내용을 알고 있을 뿐이다. 그들의 지식의 차에 두려워 하지말고, 내 자신의 길을 갈고 닦으면 좋은 개발자로 성장할 수 있다고 확신한다. 😎
이번 미션은 ‘멍토’와 함께 페어 프로그래밍을 진행하고 리뷰어 ‘휴’의 도움을 받아서 미션을 완료했다. 지난 미션이었던 레이싱카에서는 생각보다 고쳐야할 부분이 많았고 데드라인 직전에 최종 2단계를 머지할 수 있었다. 하지만 그 때 열심히 고쳐야 할 부분들을 학습을 했기 때문인지 이번 미션은 1단계 리뷰에서 바로 머지 되었고, 2단계에서도 2번의 리팩토링 후에 머지 되었다. 개념을 구축해나가는 단계이니 조급해 하지말고, 애매한 부분은 모두 질문하면서 ‘이유’를 알아가자!
이유를 알면 이해가 쉽다!
와일더의 학습 프로필 🃏
[TDD] 테스트 주도 개발 - 4
내용
- 모든 기능을 구현하기 앞서 필요한 기능에 대한 테스트 코드 설계를 하고 그에 맞게 구현을 진행
[OOP] 원시값 포장, 일급 컬렉션 - 5
내용
- LottoNumber, Payment 객체를 도출하여 ‘모든 원시값과 문자열을 포장한다.’ 규칙을 지킴
- LottoTicket, Rewords 상태와 기능을 가진 컬렉션을 포장하여 기능을 구현
- 불변성에 주목하며 기능을 구현
[OOP] Exception 을 이용한 커스텀 예외 처리 - 2
내용
- 상황에 따라 발생할 수 있는 예외를 인지하고 그에 맞는 예외를 생성하여 처리
[OOP] 상속 - 2
내용
- WinningLotto 는 보너스 번호가 필요한 Lotto 이기에 해당 부분을 상속으로 처리하였다.
[JDK] Enum 으로 상태 관리하기 - 5
내용
- 등수에 따른 상태를 관리
- 필요에 따라 enum 내의 상태를 이용하여 필요한 기능을 구현
링크
[JDK] 스트림 API - 2
내용
- 다양한 메소드에 적용하여 코드 가독성을 높임
[JDK] String.format 을 이용한 문자열 사용 - 1
내용
- 해당 기능을 사용하여 String 타입의 문자열을 조합하여 구현
[OOP] VO - 4
내용
VO 를 제대로 이해하지 않은 상태로 구현했다. (원시 값 포장 == VO 라고 생각함) 내가 어떤 의도로 VO 를 사용 했는지를 이해하고 나니 프로그램을 어떻게 리팩토링 해야할 지 보였다. 현재 프로그램에서는 상관없어 보이지만 나중에 확장성을 생각한다면, 각각의 Lotto 는 구입시기의 티켓 영수증 발행 번호가 있을 것이다. 그렇다면 같은 번호라고 할지라도 이번주 티켓과 다음주 티켓은 등수가 다를 것이다. 그래서 Lotto 는 VO 보다는 RO 를 사용하는 편이 맞다 생각되어 변경하였다.
링크
Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 목록 동일성, 동등성
[TDD] 테스트 주도 개발 - 3
내용
- 경계 값 기준 테스트하기
- 모든 예외에 대한 테스트하기
- 테스트만을 위한 테스트 코드 지양하기
- 테스트를 할 수 있는 구조로 변경하기
- 무엇을 테스트 할 것인지 이해하기
링크
[TDD] 점진적 리팩토링 - 2
내용
- 테스트를 최대한 건드리지 않아도 되게끔 리팩토링을 하려고 했지만 쉽지않았다.
- 특히 크게 변경되는 부분은 반드시 테스트를 수정해야 겠다.
- 이는 TDD 를 수행할 때, 아직도 구현에 초점을 두고 테스트를 작성한다는 사실을 깨닫게 했다.
- 다음 미션에서는 더욱 더 ‘단위 테스트’에 집중을 하고 TDD 를 진행하도록 해야겠다.
[IDE] 단축키 - 1
내용
- 리팩토링을 할 때 이용하여 리팩토링 시간 단축에 용이하였다.
- 아래 링크는 정말 깔끔하게 정리가 잘되어있었다.