과제 요약
과제 진행 소감
구현 요구사항에 대한 난이도 자체는 너무 평이했다. 아무리 프리코스더라도 이래도 되나? 싶을정도로 쉬워서 지난 기수도 찾아보니까 확실히 작년에 비해 난이도가 쉬웠던 것 같다. 그 이유가 뭔지 생각해보니, 과제에서 제한을 둔 사항이 이번에 훨씬 적었다.
대신 그만큼 예외 상황이 많이 생긴 것 같다. 입력 요구사항이 명확하지 않은 만큼 쉬웠지만 반대로 생각하면 예외가 많이 생겨서 하면 할 수록 예외처리를 많이 했던 것 같다.
지금 생각하면 현실에서 일어날 법한 상황과 더 유사하지 않나 생각이 들고, 그만큼 진짜로 운영하고자 하는 시스템 속에서는 다양한 예외에 대한 처리가 필요하지 않나 생각이 든다.
MVC 패턴
이론으로만 알고 있던 MVC 패턴을 처음으로 적용해보려고 시도해봤다.
- Model은 Controller와 View에 의존하지 않아야 한다.
- View는 Model에만 의존해야 하고, Controller에는 의존하면 안된다.
- View가 Model로부터 데이터를 받을 때는 사용자마다 다르게 보여주어야하는 데이터에 대해서만 받아야한다.
- Controller는 Model과 View에 의존해도 된다.
- View가 모델로부터 데이터를 받을 때, 반드시 Controller에서 받아야한다.
위 다섯 가지 규칙에 따라 구현을 했는데, 다른 사람들의 리뷰를 얼른 받아보고 싶다. 본 과제를 하는데 이 패턴이 과연 필요할까 생각도 들고 그럼 어떤 패턴으로 구현하는게 좋을까 이야기 해보고 싶다.
예외처리
아마 가장 많은 시간을 투자한 부분이지 않을까 생각이 든다. 처음에 기능 구현은 금방 끝났는데 여러 테스트 케이스를 작성할 때마다 새로운 예외를 발견해버렸다.
사용자의 입장에서 오류가 왜 났는지 피드백을 주고자 오류의 종류마다 새로운 IllegalArgumentException을 던져줬는데 과연 이게 좋은 방향일지 의문이 든다.
적은 메소드로 여러 예외를 처리하는 게 좋을지, 나눌 수 있는 만큼 케이스마다 새롭게 예외처리를 해주는 게 좋을지 다른 사람의 의견도 궁금하다. 실제 서비스는 어떻게 운영이 될까, 개발자들은 어떤 방향성을 가지고 예외처리를 하는게 좋을까, 단순화가 좋은지 구체화가 좋은지 가장 고민을 많이 했던 부분인데 이번 과제는 앞서 말한 것처럼 사용자가 잘못 입력을 했을 때 그에 맞는 피드백을 주고 싶어서 구체화를 목표로 진행했다.