해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)
수강 회고
오늘로 벌써 팀 프로젝트 수행의 마지막 직전의 날이 되었다. 내일 오후에는 별도로 전체 공유 및 클래스별 피드백 시간을 가지기에 사실상 오늘이 거의 마지막 팀 프로젝트 수행 시간이었다. 다행히 오늘로 당초 이번 팀 프로젝트에서 팀원들간에 목표했었던 기능 구현까지는 해낼 수 있었다.
사실 이번 프로젝트를 진행하면서 팀에서 프론트 엔드 역할을 하고 계시는 Khan과 Nick이 더 나은 UX 제공을 위한 좋은 의견들을 주시고 아울러 백엔드 역할을 하고 있는 나와 Hanse의 의견을 잘 수렴해주신 덕에 팀 프로젝트를 수행함에 있어 큰 어려움은 없었던 것 같다.
이번 팀 프로젝트는 마스터즈 코스 과정 상 첫 번째 팀 프로젝트였기에 팀원간 적극적인 소통과 '즐겁게' 프로그래밍하는 것을 목표로 하고있었다. 그렇기 때문에 웹 앱의 완성도 보다는 단순 기능 구현을 위주로 프로젝트를 수행했었는데 막상 기능을 다 구현해보고나니 백엔드 단에서 예외처리나 단위 테스트 코드를 작성하지 않았던 것이 아쉬운 점으로 남았다.
학습 회고
- 투두리스트 구현 프로젝트
- 팀원들(백 엔드 2명, 프론트 엔드 2명)과 zoom 회의실에서 학습
인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다.(로버트 C. 마틴)
어떤 남자라는 클래스 안에 기념일 챙기기() 메서드, 출근하기() 메서드, 효도하기() 메서드, 사격하기() 메서드가 있다고 가정해보자. 이때 여자친구 클래스는 남자 클래스를 의존하는데 기념일 챙기기() 메서드만 사용할 것이고, 직장상사 클래스는 남자 클래스를 의존하여 출근하기() 메서드만 사용할 것이고, 어머니 클래스는 남자 클래스를 의존하여 효도하기() 메서드만 사용할 것이고, 소대장 클래스는 남자 클래스를 의존하여 사격하기() 메서드만 사용할 것이다.
만일 이러한 상황에서 단일 책임 원칙을 적용한다면 남자 클래스를 남자친구 클래스, 사원 클래스, 아들 클래스, 소대원 클래스로 나누어 설계했을 것이다. 하지만 인터페이스 분리 원칙은 이처럼 각종 기능을 갖고있는 남자 클래스를 그대로 두고 남자친구 인터페이스, 사원 인터페이스, 아들 인터페이스, 소대원 인터페이스로 나누어 클라이언트가 이를 의존하도록 설계하는 것이다. 이렇게 되면 클라이언트 입장에서 의존하는 인터페이스에는 불필요한 기능이 없게 된다.
이처럼 단일 책임 원칙과 인터페이스 분할 원칙은 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다. 프로젝트 요구사항과 설계자의 취향에 따라 단일 책임 원칙이나 인터페이스 분할 원칙 중 하나를 선택해서 설계할 수 있는데 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 할 수 있다.
인터페이스 분할 원칙에서는 인터페이스 최소주의 원칙이 매우 중요하다. 인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라는 것이다. 인터페이스는 그 역할에 충실한 최소한의 기능만 공개하라는 것이 중요하며, 인터페이스는 “~할 수 있는(is able to)”이라는 기준으로 만드는 것이 정석이다.
학습 참고자료
- 위키북스 출판 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'
좋았던 점
- 오늘로 이번 팀 프로젝트에서 Hanse와 함께 목표하는 기능 구현까지 해낼 수 있어 보람있었습니다. 🥂
아쉬웠던 점
- 약 2주간의 투두리스트 팀 프로젝트를 진행하면서 기능 구현에 집중하기 위해 스프링 웹 앱의 단위 테스트 및 예외처리 작업을 별도로 하지 못한 점이 아쉬웠습니다. 😥
- 오늘 처음으로 호눅스와 (zoom을 통해) 둘이 대화하는 시간을 가졌는데, 시간이 짧아 아쉬웠습니다 🤣
이전 보다 개선되었던 점
- 지난주부터 약 2주간 프론트 엔드 팀원분들과 팀 프로젝트를 수행하면서 점점 소통이 원활하게 되는 기분이 들었습니다. 👍