1주차 회고 - 지나치게 고민하지 말고 일단 해보기

1. 마음가짐

OT에서 언급한 메타인지를 떠올리며 나는 어떤 사람이가 생각해봤다. 나는 뭘 하던 잘하고 싶어하는 성격 탓에 시작 단계에서 삽질을 너무 많이한다. 이런 나를 생각하며 과제를 시작하였다.

2. 과제 해결하기

과제는 문자열을 파싱하는 단순한 알고리즘의 과제였다. 먼저 백준이나 프로그래머스에서 문제를 해결할 때처럼 코드를 짜봤다. 프리코스는 여기서 끝나선 안된다. 문제를 해결할 때 사용한 핵심 로직을 분리하고, 입력받고 출력하는 로직을 분리했다. 그다음 입력에 잘못된 값이 들어간 경우를 걸러주는 검증부를 만들었다.

분리한 코드들을 MVC에 맞게 리팩토링해 보았다.

• view
  • InputView
  • OutputView
• validation
• model
  • domain
  • dto
• controller
  • MainController

크게 이런 구조로 설계하였다. 만들면서 아래와 같은 의문이 들었다.

• 검증 부분이 핵심 로직과 밀접한 연관이 있는데 분리하는게 맞나?
• dto를 잘 쓰고 있나?

다른 사람들의 코드리뷰를 하고 내 코드를 리뷰 받으며 이 의문을 어느정도 해결할 수 있었다. 결과적으로 검증 부분은 도메인과 합쳐 구현하는게 좋을 것 같았다. 검증할 때 입력값을 단순히 검사하고 끝날 수도 있지만, 핵심 비즈니스 로직이 동작하는 동안에 검증해야하는 부분도 있었다. 나는 dto를 사용할 때 단순히 데이터의 형태만 정의하지 않았고, 데이터의 행동에 대한 코드도 포함하였었다. dto가 아닌 유틸리티 클래스의 가까운 코드를 만들어버린 것이다. 이 방식은 내 코드가 절차지향적인 코드가 되게 하였고, 코드 간의 결합도가 높아지는 결과를 초래했다.

3. 더 공부해볼 것

• 정규식
• dto
• 유틸리티 클래스와 객체지향

기능을 구현할 때 정규식을 쓰면 편할 것 같다는 생각을 했었는데 생각보다 구현에 어려움을 겪어 포기했었다. 이부분을 좀더 공부하여 또 필요한 경우가 생기면 공부하여 잘 써먹어 보고 싶다.

코드리뷰를 통해 dto의 사용이 잘못 되었고, 절차지향적인 코드를 사용중이라는 문제점을 발견하였다. dto와 유틸리티 클래스를 사용한 절차지향 프로그래밍, 객체지향 프로그래밍에 대해 더 공부해야겠다.