2주 차 미션 : 로또(Lotto) - TDD
저장소 : github.com/next-step/java-lotto/tree/jhhj424
문자열 계산기 리뷰 : github.com/next-step/java-lotto/pull/1045
로또(Lotto) 1차 리뷰 : github.com/next-step/java-lotto/pull/1079
로또(Lotto) 2차 리뷰 : github.com/next-step/java-lotto/pull/1114
로또(Lotto) 3차 리뷰 : github.com/next-step/java-lotto/pull/1130
후기
- 클래스 분리가 쉽지 않다. ( 어떤 역할을 위임할 것인가.. )
- 모든 원시 값과 문자열을 포장하는 과정에서의 테스트 코드 작성이 쉽지 않다.
- 클린 코드를 지키는 과정은 조금 나아진 것 같다.
- 단위 테스트 작성보다 TDD는 조금 더 어렵다.
이번 과정에서 중심적으로 연습할 객체지향 생활 체조 원칙
- 모든 원시 값과 문자열을 포장한다.
- 줄여 쓰지 않는다(축약 금지).
- 일급 콜렉션을 쓴다.
이번 과정의 목표 경험 4가지
- TDD 기반으로 프로그래밍하는 경험
- 메소드 분리 + 클래스를 분리하는 리팩토링 경험
- 점진적으로 리팩토링하는 경험
내 코드 피드백
비싼 객체(객체를 만드는데 비용이 많이 듬)는 static final로 정의해서 사용하면 메소드 생성 시마다 호출하지 않아도 된다.
이런 점까지 생각하면서 코드를 작성하면 좋을 듯싶다.
상수 네이밍에 대한 피드백이었다.
저번 과제에서도 지적을 받았던 사항인데, 이번에 또 지적을 받았다니 큰 실수였다.
앞으로는 확실한 네이밍을 하도록 연습 또 연습해야겠다.
역할과 책임을 다시 한번 신경 써서 클래스 분리를 하는 것이 중요할 것 같다!
테스트 코드 작성을 이전에 많이 접해보지 않아서, 라는 핑계로..ㅎ 몰랐던 부분에 대한 피드백을 받았다.
실무에서 사용하는 TC 작성에 대한 팁(?)을 많이 받은 것 같다.
클래스를 정의할 때 확실한 역할에 대한 명명을 해야 할 것 같다.
이게 처음에는 생각보다 쉽지 않았지만, 이번 과정을 통해 많이 좋아졌다고 생각한다!
해당 피드백은 정말 와닿았었는데, 유연하게 대처해야 할 객체를 테스트해야 할 클래스 안에서 직접 생성을 하고 있다 보니 테스트 코드 작성이 정말 어려웠다.
해당 부분에 대한 피드백을 받고, 상위로 올리게 됨으로써 TC작성에 수월해졌었다.
꼭 기억하자, 강한 결합 -> 테스트 작성 어려움! -> 리팩토링 필요👍
인스턴스 변수에 대한 정의를 다시 한번 생각하고 코드를 작성하는 편이 좋았을 듯싶다.
모든 인스턴스에서 동일한 값을 사용하기 때문에 이럴 때는 클래스 변수로 선언하는 게 좋을 것 같다.
객체지향적인 코드 작성에 심혈을 기울여야겠다😂
해당 피드백을 받고 나서는 값을 꺼내는 부분은 정말 꼭 필요한 게 아니라면 지양하고, 메시지를 전달하는 방향으로 코드를 작성하게 되었다.
내가 기존에 잘 몰라서 사용하지 못했던 자바의 문법들 또한 피드백을 해주셔서 정말 좋았다👍
메인 애플리케이션에서 너무 장황한 코드가 작성되어있다 보니, 가독성을 많이 헤치는 것 같았다.
전반적인 흐름을 가지는 도메인 객체를 생성해서 관리하는 것 이 좋은 방법일 수 있다👌
테스트 코드 작성을 실무에서 접하지 못하다 보니, 이런 피드백도 좋은 영향이 된 것 같다.
앞으로는 Junit 뿐만 아니라 AssertJ 라이브러리도 잘 활용해봐야겠다.
기본적인 원칙인데 생각 없이 코드를 구현했나 싶다..
코드를 작성할 때 기본 원칙들을 잘 지켜보자!
인터페이스를 활용한, 다형성을 통해서 테스트하기 좋은 코드를 작성하는 게 좋을 듯하다.
(인터페이스를 남용하자는 뜻은 아니다)
이건 개인적인 질문이었다.
원래도 LottoTicket에서 winningNumber와 비교해서 몇 개의 winningNumber를 가지는지 판단을 했었는데, 보너스 번호인지 확인하는 책임도 LottoTicker에게 위임하는 편이 현재 작성된 내 코드에서는 더 통일성이 있어 보이는 것 같았다.
이런 세세한 부분과 코드 전반적인 구성까지 피드백을 해주셔서 정말 좋았다👍
적절한 인스턴스 변수의 활용을 통해, 메소드의 인자 값을 줄줄이 쓰지 않을 수 있었다 :)
메인 애플리케이션의 흐름을 대략 이런 방식으로 잡는 편이 코드의 가독성 면에서 확실히 좋은 것 같았다.
이전에 내 메인클래스의 코드는 너무 장황했다.. 해당 피드백을 받은 후에 전체적인 코드를 갈아엎진 못했지만 메인클래스에서의 흐름을 비슷하게 변경했다.
인터페이스를 구현한 구현체에서 같은 상수를 사용하고 있었다, 이런 경우에는 인터페이스에서 선언하는 편이 코드 중복을 줄일 수 있는 방법이다!👍
추가적인 피드백 사항이었는데, 반영해봐야겠다.
이전에 사용하던 메소드를 삭제하지 않고 그대로 놔두고 있었다, 리팩토링 하면서 사용하지 않게 된 메소드는 방치하지 말고 삭제하는 게 좋을 것 같다.
좋은 채찍질에 당근까지 주시니 감사할 따름이다 😁
끝으로...
이번 2주 차 미션에서는 1주 차에서 알게 된 내용 + 피드백 사항을 열심히 반영하면서 구현을 하려 했지만, 그래도 놓친 부분이 드러나는 미션이었다고 생각한다.
강한 결합을 지양해서 테스트 코드를 작성하기 쉽게 구조를 갖추는 편이 좋을 듯싶다.
코드를 작성하고 내가 작성한 코드를 나 자신이 리뷰한다고 생각하고 한번 쭉 읽어보면서 객체지향적인 사고를 가지고 리팩토링을 하는 게 깔끔한 코드를 작성하는데 큰 도움이 될 것이라고 생각한다.
TDD를 경험하는 게 큰 도움이 되었고, 앞으로도 TDD를 적용한 코드 작성을 즐겨보는 것도 좋을 것 같다. ( 처음 학습할 땐 과하게 하는 것도 큰 도움이 된다. )
꼼꼼한 피드백과 실무에서 사용하는 TC 작성 등의 팁을 얻을 수 있어서 너무 값진 일주일이었다고 생각한다.
댓글