우아한테크코스 2주차 회고
인트로
우아한테크코스 6기 프리코스 2주차 숫자야구게임 회고입니다. 🚗
1주차 코드리뷰
- while문 내부 조건을 true 말고 명시적으로 바꿔주기
- 변수명 잘짓기 (특히 boolean형)
- 리펙토링 과정에서 모든 수정사항 고려하기
- 불필요한 static이 선언되어 있었음
- if문 내부 조건문이 부정문이면 clean code 규칙에 위배된다.
- java 17부터는 stream()에서 toList();를 활용해 list로 반환가능
- 메서드의 순서 public 메서드에서 private 메서드를 뺀 경우 순차적으로 분리
- DI 방식 통일화
코드리뷰를 통해 위와 같은 다양한 정보를 알 수 있었고 2주차 코드에 녹여보려고 노력했습니다!
회고
설계의 중요성을 다시 한번 깨닫는 시간이었습니다.
목요일에 회고록을 업로드 하려고 하였으나 코드리뷰를 보고ㄴ 2주차 미션에 대해서 생각이 많아져 다시 작성을 하였다.
일단 이번 미션을 진행하면서 자동차 전진 조건 요구사항 중 4 이상을 4 초과로 구현을 테스트를 몇시간동안 통과하지 못했다.
당연히 해당 부분을 올바르게 구현을 했을거라고 생각을 하였으나 아니었다. 내자신을 믿기보단, 내가 작성한 코드를 믿고 가야한다는 생각을 해야겠다란 생각을 했다.
물론 1주차에 비해서 개선된 부분은 있었다.
- Class간의 DI를 매개변수로 받아서 해결한 점
- 조금더 유연한 stream을 사용한 점
- 논리적인 TestCode를 사용한 점
1. Class각의 DI를 매개변수로 받아서 해결
기존에 의존성 주입을 생성자에서 바로 주입하거나 매개변수로 받는 등 기준이 없이 코드를 작성하였다. 하지만 테스트코드를 작성하다가 매개변수로 의존성이 주입이 되어야지 객체간에 유연성이 높아지는 것을 느꼈다. 따라서 ComponentFactory로 객체를 생성을 담당하는 class를 만들어 해결을 하였다.
2. 유연한 stream() 사용
일급컬랙션을 적용하다보니 List형 객체를 맵핑이 필요했다. for문으로 구현을 하려고 했으나 비효율적이라는 생각에 Stream()을 사용하여 해결을 하였다.
3. 논리적인 TestCode를 사용
Given-When-Then 패턴을 통해 해당 메서드가 논리적인 흐름으로 단위 테스트가 작동하는지 여부를 고려하며 작성을 하였다. 그리고 진정한 단위 테스트를 하려면 다른곳에서 주입받아서 사용하는 메서드는 전부 mock으로 처리를 해야지 진정한 단위테스트임을 추후에 알게 되어서 3주차부터는 적용을 해볼 생각이다.
아쉬운접
이번주 미션을 진행하면서 아쉬운점을 남겨야지 추후에 똑같은 일이 발생하는 불상사를 줄일 수 있을 거 같아 남겨보겠다.
- 요구사항 명확히 읽기
- 내 자신을 믿기보단 내 코드를 믿기
- 모든 상황을 고려해서 예외처리하기
- 현재 요구사항에서는 당연하게 발생하지 않는 에외이지만 추후에 발생할 상황을 고려해 예외처리를 한다.
- 메서드 명 잘 짓기
- 메서드 명은 프로그램 입장에서 지어야 하는것 같다
- 어떤일을 하는지 표현해주는게 좋다.(“어떻게 하는지”는 로직의 흐름을 읽는데 방해가 된다.)
- 로직을 조금더 생각하고 작성하자
- racing car에서 가장 멀리간 차를 구할 시 정렬후 최고값을 찾았다.
- 최고값을 찾을때 굳이 정렬을 할 필요없이 탐색으로 찾을 수 있었다.
- 입출력시 한번에 모아서 출력하기
- 리펙토링시 모든 경우다 생각하기
- 앞서 말했던 ComponentFactory 구현시 일부분은 해당 방식으로 구현을 못했다. 실수다..!
마무리
아쉬움이 많이 남는 2주차였다. 긴말하지 않겠다. 3주차에서는 적어도 실수해서 아쉬움이 남는 코드를 작성하지 않겠다.
Leave a comment