[우아한테크코스] 프리코스 3주차 - 지하철 노선도 미션

3주차 과제 회고

새로 알게 된것

1. 객체에 메시지를 보내는 법
2. 비즈니스 로직과 UI 로직을 분리하라
3. 동작하게 만들고, 제대로 만들고, 빠르게 만든다
4. enum의 다양한 활용법

아쉬웠던 점

1. 중복 코드가 많은 것
2. 살아있는 문서를 만들지 못한 것
3. 객체지향적이지 못한 설계
4. 테스트 코드를 제대로 작성하지 못한 것

객체에 메시지를 보내라

"메시지를 보낸다"라는 개념이 처음엔 생소했습니다. 그 의미를 곰곰히 생각해보았고 제가 그 동안 객체를 객체스럽게 사용하지 못하고 데이터 덩어리처럼 사용하는 경우가 많았다는 걸 깨달았습니다. 덕분에 정보만 담고 있는 데이터 덩어리가 아닌 역할과 책임을 가지고 있는 객체를 만들 수 있게 되었습니다.

 

비지니스 로직과 UI 로직을 분리하라

그 동안 하나의 도메인에 관련된 역할은 모두 모아놓고 구현해왔는데 비즈니스 로직과 UI를 분리하면서 좀 더 책임이 분명한 객체들을 만들 수 있었습니다. 레이어를 나누며 결합도가 낮아지는걸 경험하면서 더 많은 아키텍처들에 대해 알고 싶어졌습니다. 도메인, MVC, 서비스 레이어 등 여러 아키텍처를 조금씩 공부하면서 기능 구현 뿐 아니라 설계의 본질이라고 생각되는 "코드를 어떻게 배치할 것인가"를 고민하는 즐거운 시간이었습니다.

 

동작하게 만들고, 제대로 만들고, 빠르게 만든다

처음에는 완벽한 설계를 하고 구현을 시작해야한다는 이상한 강박에 사로잡혀 이틀 정도 거의 아무 코드도 작성하지 못하는 고난이 있었습니다. 좋은 설계를 가지고 시작하고 싶다는 마음 덕분에 공부를 하며 새로운 지식을 얻을 수 있었지만 과제의 기한과 제 능력을 제대로 파악하지 못하고 시간이 허비되었다는 생각도 듭니다.

그 때에 포비님의 세미나 중 "처음부터 완벽한 설계는 없다. 일단 동작하는 코드를 만들고, 그걸 개선해라"(정확한 대사는 기억이 안나지만 비슷한 의미였습니다..) 라는 말씀을 듣고 마음껏 똥(?)을 만들어내기 시작했습니다. 신기하게도 아무리 머릿속으로, 노트에 그려도 감이 안잡히던 설계가 보이기 시작했습니다.

 

enum

메뉴 선택지를 구현할 때 반복적인 조건문 없이 구현하고 싶어서 방법을 찾던 중 enum을 알게 되었습니다. enum을 활용하면 좀 더 가독성 좋고 안정적인 조건분기를 할 수 있을 것 같아서 적용해보았습니다. 다른 언어와는 달리 하나의 클래스처럼 동작하기 때문에 많은 일들을 할 수 있다는 걸 알게 되었는데 그 중 새로웠던 활용법은 필드로 Functional Interface를 가질 수 있어서 enum이 로직을 가지는 것이 가능하다 는 점 입니다.

 

반복하지 마라

메뉴 선택지를 enum으로 구현한 덕분에 조건문 지옥은 피했지만 이번엔 선택지(enum)의 적절한 위치가 어디일까라는 고민이 생겼습니다. 사용자가 메뉴를 선택하는 어플리케이션 로직은 컨트롤러의 역할이라고 생각해 컨트롤러의 Inner class로 배치했지만 Inner class는 상속이 불가하다는 점 때문에 컨트롤러마다 선택지를 직접 만들어 주었고 변경이 있을 때마다 선택지 클래스를 일일이 찾아서 수정해주었습니다. enum의 요구사항이 변경될 때 마다 다른 enum에서도 똑같은 작업을 하며 비효율적으로 일했습니다. 컨트롤러와 enum을 효과적으로 관리할 수 있는 방법을 찾지 못했고 선택지라는 클래스끼리 어떤 관계도 만들어주지 못한 것이 큰 실수였습니다.

만약 리팩토링을 한다면 컨트롤러와 메뉴(enum)의 분리하여 컨트롤러와 메뉴 모두 메뉴 인터페이스를 의존하게 만들 것 같습니다.

 

객체지향을 버린 설계...

자바에서 MVC 패턴을 접해보는건 처음이라 객체지향적 설계를 전혀 하지 못한것이 아쉽습니다. 로직을 레이어로 분리하면서 static 메소드를 자주 쓰게 되었는데 제 때에 개선하지 못하고 컨트롤러, 서비스 대부분의 로직을 static 메소드로 구현해버렸습니다. 나중에 제 코드를 보니 클래스를 사용할 뿐 전혀 객체를 쓰지 않고 있다는 사실을 알았고 오히려 절차지향에 가깝다고 생각했습니다.