[우테코 프리코스] 2주차 회고

이번주에는 자동차 경주 게임 미션을 수행하였다. 카트라이더나 마리오 카트 같은 복잡한 게임은 아니지만 확률적으로 자동차를 이동시키고 먼저 끝에 도달한 사람이 이기는 게임이었다.

 

경주 게임 미션을 수행하면서 저번주 리뷰에서 알게 된 사실과 개선 방향들을 참고해서 코드를 작성하였다. 이번에는 애플리케이션의 구조를 명확하게 해 보기 위해 MVC 패턴을 사용해 보았다. 뷰와 컨트롤러, 모델을 분리해 놓고 비즈니스 로직은 최대한 모델에서 수행하도록 하였다. 이렇게 하니 각각의 레이어가 가지는 책임이 좀 더 명확해진 것 같다. 다만, 이번에는 모델들이 갖는 책임들이 적절하게 분배가 되었는지 각 계층 간 의존도는 없거나 낮은지 좀 더 생각해보아야 할 것 같다.

 

이번 주 리뷰에서 나온 내용

1. 람다식 매개변수에도 불명확한 변수 이름보다 구체적인 이름 사용하자. 아무리 반복문이라고 해도 약자나 한 글자 변수명은 좋지 않은 것 같다. 다음부터는 for문을 제외하고는 i, j, k 등 변수명을 지양하려고 한다.

 

2. 숫자 상수들에 대한 미흡한 처리가 문제가 되었다. 문자열 상수는 enum으로 처리하였으나 0, 9, 4 등 확률 계산이나 고정된 상수의 경우 처리를 하지 않았었다. 이 부분은 꼭 신경 쓸 필요가 있다. 반복문에서의 숫자 사용 처리를 어떻게 할지도 신경 쓰자.

 

3. 배열보다 컬렉션 타입을 사용하자. 컬렉션 타입이 더 많은 api를 제공하고 여러 가지 이점이 있는 것으로 알고 있다. 이펙티브 자바에서도 해당 내용을 본 것 같아서 좀 더 연구해보려고 한다. 

 

4. 메서드 순서에 대해 고민해보려고 한다. getter와 로직 메서드 중 어느 것이 먼저 나오는 것이 좋을지 결정이 필요하다.

 

5. 전역 사용이 아닌 util 클래스를 util 패키지에 넣는 것인가 여부 util 클래스는 애플리케이션 전역에서 사용할 수 있어야 하지 않는가에 대한 의문을 해결하기 위해 조사하고 고민해보려고 한다.

 

6. enums 패키지의 이름을 constant로 바꾸려고 한다. enums 자체도 키워드 회피를 해야 하는 것도 있고 의미상 상수 모음인 constant가 더 나을 것 같다.

 

이번 주 고민거리

 

함께 나누기에서 DTO 사용에 관한 얘기가 활발하게 나오는 것 같다. DTO 변환의 책임은 어디인가와 모델이 DTO에 의존해도 되는가에 대한 것이다. 개인적인 생각으로는 모델이 DTO를 알아도 상관없지 않나 싶다. 뷰의 모델에 대한 의존을 피하기 위해 DTO를 사용하는 것인데 뷰나 모델이 서로를 모르기만 하면 되지 DTO는 알아도 괜찮다고 생각한다. 그렇다고 컨트롤러에 변환 로직을 넣는 건 컨트롤러가 모델의 로직을 알게 되지 않는가? 일단 레이어드 아키텍처라면 서비스 레이어에 변환 로직을 넣으면 될 것 같은데 MVC에서는 모델이 가져가는 것 이 맞지 않나 싶다.

 

수정이 필요한 로직들은  인터페이스로 추상화하고 의존하는 객체들이 구체 클래스가 아닌 인터페이스에 의존하게 하는 것이 좋을 것 같다. OCP적으로나 DIP적으로나 더 나은 설계가 될 것 같다. 일단 생각나는 부분은 유효성 검사 부분이다. 놓친 부분이 있거나 새로운 제약 사항이 생겼을 때 validator 인터페이스를 상속하는 객체를 교체해주기만 하면 변경에 닫혀 있는 구조가 될 것으로 보인다. 추가적으로  controller나 model, view에도 적용할 수 있을 것 같긴 한데 그 정도 설계가 필요할 정도로 변경이 잦은 프로젝트인가 잘 생각해봐야 할 것 같다.