시작하며
1주차 프리코스 과제가 끝나고, 개인적으로 세웠던 목표를 이번 주차 회고 전에 되짚어보려 한다.
세웠던 목표는 아래와 같다.
- MVC 패턴 도입해보기
- 커밋 단위 더 잘게 쪼개기
- 커밋 메시지 상세히 작성하기
- 각 계층 간 분리 확실히 해보기
- 추상화 적극적으로 활용해보기
MVC 패턴 도입해보기
-> 사실 구조에 대한 간단한 이해와 아래 두 영상을 보고 구조를 작성하고, 구현을 진행했다.
[10분 테코톡 - 제리님의 MVC 패턴]
https://www.youtube.com/watch?v=ogaXW6KPc8I
[10분 테코톡 - 도기님의 MVC 패턴]
https://www.youtube.com/watch?v=Yzx-z6kCD2A
구현에서는 특히 제리 님의 영상이 큰 도움이 되었던 것 같다.
(MVC 패턴의 구현에 중점을 두고 설명하셔서 바로 코드에 적용해가며 하기 좋았습니다.)
다만, 중간 중간에 컨트롤러의 책임이 커지는 등의 아쉬운 부분이 좀 있었다. 아래에서 더 상세하게 적어보겠다.
커밋 단위 더 잘게 쪼개기
-> 나름 성공적? 인듯 하다. 저번 주 미션에는 잘 몰라서 사용하지 못했던 깃 커밋 메시지에 scope를 추가하고, 기능별로 커밋 단위를 나눠 진행했다.
커밋 메시지 상세히 작성하기
-> 아쉬웠다. 커밋 메시지 바디 작성이 소홀했던 것 같다. 전체적으로 바디에 디테일을 적기보다는 메시지 한 문장에 모든 의미를 담으려 했던 것 같다.
(이제보니 조금 모호한 듯한 커밋 메시지)
각 계층 간 분리 확실히 해보기
-> 아쉬웠다. 이것도 설계와 관련된 부분이기에 아래에 작성하겠다.
추상화 적극적으로 활용해보기
-> 나름 괜찮게 사용한 듯 하다.
승리자 판별 로직과 자동차 도메인을 추상화하여, 확장성을 고려해보았다.
조금 아쉬웠던 점은 MVC 구조에 대한 이해 부족인지, 개인적으로는 적극적으로 사용하진 못한 것 같다.
🚩과제 내용
2주차 과제 내용은 아래와 같았다.
그리고, 저번 주차와는 다르게 추가적인 프로그래밍 요구사항이 생겼다.
큰 제약사항은 아니라서, 구현에 어려움은 없었던 것 같다.
그나마 가장 신경 쓰이는 부분은 여기였다.
함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
이 부분을 고려해서, 최대한 메서드를 기능별로 쪼개서 구현하려 노력했다.
🛠️ 설계
처음에는, 정말 순수하게 Model, View, Controller 만을 기반으로 구현을 진행해보려 했다.
(처음에 생각했던 MVC 구조)
하지만 이렇게 설계하면서 자동차 경주 컨트롤러의 책임이 너무 커졌다.
그렇게 약간의 고민을 거쳐서 이런 구조로 변경했다.
자동차 입력을 처리하는 컨트롤러와 시도횟수, 승리자 판별 로직을 담당하는 컨트롤러로 분리했다.
사실 추상화는 요구사항에는 없었지만, OCP를 고려해봤을 때 자동차 도메인을 추상화하는 것까지는 괜찮은 선택이었던 것 같다.
자동차 도메인의 추상화는 괜찮았지만, 그 구현체인 RacingCar 구현체를 보았을 때, 추상 메서드를 오버라이딩한 accelerate()의 구현 방식이 좋은 방식은 아니었던 것 같다.
package racingcar.model;
import camp.nextstep.edu.missionutils.Randoms;
public class RacingCar extends Car {
private static final int RANDOM_MIN = 0;
private static final int RANDOM_MAX = 9;
private static final int ACCELERATION_THRESHOLD = 4;
public RacingCar(String name, int position) {
super(name, position);
}
@Override
public void accelerate() {
if (Randoms.pickNumberInRange(RANDOM_MIN, RANDOM_MAX) >= ACCELERATION_THRESHOLD) {
position++;
}
}
}처음에 오버라이딩을 진행했을 때에는 이것도 하나의 전진 방식이니 이렇게 구현해도 괜찮겠지? 라는 생각이었는데,
제공받은 메서드도 라이브러리였기에 결국 도메인이 라이브러리에 의존해버리는 상황이 되버리고 말았다.
그리고 승리자 판별 로직을 단순히 인터페이스로 분리했다고 해서 유의미한 추상화가 되었는지는 이제와서 보니 오히려 그렇지 않은 것 같다고 느꼈다.
가장 어려웠던 부분은 역시 책임 할당인 것 같다.
컨트롤러에 자꾸만 큰 책임이 쏠렸고 이를 어디까지 허용할 것인지도 큰 고민이었다.
마지막으로 정적 메서드 남용이었다.
계속해서 정적 메서드로 일괄 처리하는 부분이 많다보니, 테스트하기 어려운 코드가 만들어졌고
결국 통합 테스트를 진행하는 테스트 코드 밖에 남지 않게 되었다.
사실 의도했던 바는 클래스에 다른 클래스에 대한 의존성(클래스 변수)을 줄이고자 했던 것인데..결과적으로는 테스트하기 어려운 코드가 되었던 것 같다.
이번에도 크게 복잡한 예외 케이스는 없었던 것 같다..!
😎 미션 종료 후
미션 종료 후 BE 파트 지원자들에게 온 2주차 공통 피드백이다.
(사실 앞부분 내용이 형식적인 조언/응원일지라도 큰 힘이 되었던 것 같습니다.)
'살아있는 문서' 라는 문구가 참 와닿았다.
싸늘하게 식어 죽어있던 내 README 파일을 다시 보게되는 문구였다.
다른 지원자 분들의 커밋을 잠깐씩 볼때마다 README 문서를 수정하는 모습을 볼 수 있었는데,
처음에 다 작성하고 이에 맞춰서 구현하는게 맞지 않나?
라는 고정관념이 강하게 박혀있던 것 같다.
이 생각을 환기할 수 있는 피드백이었다.
이 피드백 또한 좀 인상 깊었다.
항상 상수, 클래스 변수, 인스턴스 변수 순서를 어떻게 할까 고민했던 상황이 많았는데 확실한 답이 되었다.
그리고..
그냥 나 그 자체였다.
테스트 코드 대부분이 통합 테스트였던 점에서, 어느 시점부터 작성하던 테스트 코드가 통합 테스트 코드가 되는 상황이 많았던 것 같다.
이번 주차 피드백에서 받은 작은 과제이다. 조금 고민해보면서 스스로 정리해보려고 한다!
👀 느낀 점
이번에는 MVC 패턴을 적용하면서, 계속 들었던 생각이
'이게 정말 MVC 패턴을 잘 적용하고 있는 걸까?'
이다. 물론 구현에 완벽한 정답은 없었고, 이런 궁금증 덕에 위에서 언급했던 테코톡 영상이나 이론 등을 찾아보면서 좀 더 구현할 때 구조에 대해 깊이 고민해볼 수 있던 시간이었던 것 같다.
사실 나 스스로와의 약속을 지키지 못할까 두려워 저번주 목표에 TDD 도입하기 를 적지 못했다.
그래서 이번 주차 과제에서 조금씩 시도를 해보았는데 결국 통합 테스트만 먼저 작성하고 작업하는 꼴이 되어버렸다. 의식하고 문제를 단위 별로 쪼개보는 연습이 필요하다고 생각되었다.
마지막으로, 생각보다 도메인 로직이 다양했던 것 같다.
관점에 따라서 거리 를 도메인으로 둔다던지, 자동차가 아닌 참가자 의 관점으로 본다던지,
다양한 관점은 내가 생각하던 구조에서 벗어나 다른 구조를 고민해보는 시간이 되었다.
✒️ 다음 주 목표
- 단위 테스트 작성하기 (문제를 더 작게 쪼개서)
- TDD 도입해보기 (완벽하진 않아도 계속 시도해보자!)
- 적절한 의존성 주입 활용하기
- 정적 메서드 사용 줄여보기
추가로..
커뮤니티를 보면 정말 잘하는 분들이 많다고 느꼈고 무의식 중에 다른 지원자분들이랑 나를 비교했던 것 같다.
남은 프리코스 기간동안, 나 스스로의 성장에 좀 더 집중하게 되는 시간이 되었으면 좋겠다😀
