우테코 4주 차 프리코스 회고 (bridge)

squareyun·2022년 11월 22일

회고

목록 보기

3/4

[2022.12.14] 우아한테크코스 5기 지원 결과, 1차 심사(자소서, 프리코스)에서 탈락했습니다.

4주간 진행한 프리코스가 오늘부로 끝이 났다. 바쁜 일정 가운데 시간을 쪼개가며 프리코스를 진행했다. 투자한 시간이 아깝지 않다.

이번 주차에서는 조금 더 구체적인 클래스 관련 요구 사항이 추가되었다. MVC 패턴을 학습하고 적용해보라는 의미였던 것 같다. 또한, 인터페이스를 이용한 다형성을 연습하라는 취지도 있는 것 같다. 이 내용들을 곰곰이 생각하며 활용해보지 않았었는데, 이번 기회를 통해 학습하고 적용할 수 있어서 좋았다.

후회하는 일이 없도록 프리코스에서 얻어갈 수 있는 것을 모두 얻어 가려고 노력했다. 어떤 의도로 이 요구 사항을 제시하였는지 생각하며 진행해보기도 했다. 어려웠다. 하지만 신났다. 어떻게 손을 대야 할지 감도 오지 않았던 초반에 비해, 지금의 나를 보면 상당히 성장했다고 생각한다. 특히 이번 주차를 진행하고 MVC 패턴에 대해 답답했던 마음이 드디어 풀렸다. 한 주가 지나면서 꾸준히 성장하는 나를 보니 기뻤다.

한편으로 결과 발표를 앞둔 상황에서 두렵다. 체계적인 시스템과 자유 주도 학습의 경계를 아우르는 우아한 테크코스 프로그램에 너무 만족했기 때문이다. 어떻게 될지는 결과가 나와야 알지만, 결과가 어떻든 프리코스에 임했던 자세를 잊지 말자.

회고록을 프로젝트를 모두 마친 후 작성하려고 하지 말자.
겪었던 일들을 우선 간략하게 적어두고, 추후 이야기를 풀어쓰니 수월하게 작성할 수 있었다.

3주 차 공통 피드백에서..

💡 객체는 객체스럽게 사용한다.
getter를 사용하는 대신 객체에 메시지를 보내자.

어디선가 어렴풋 들었던 내용이었다. 짧은 문장이지만, 어려운 문장이다.

객체지향 프로그래밍은 객체가 스스로 일을 하도록 하는 프로그래밍이다.
getter를 남용하게 되면, 디미터 법칙을 위반할 수도 있다. 그 예시로 열차 전복 코드라고 알려진 코드가 만들어진다.

//디미터 법칙 위반 예시 - 열차 전복 코드 
object.getChild().getContent().getItem().getTitle();

어쩔 수 없이 출력 등의 이유로 사용해야만 할 수도 있다. 그것을 강제하는 것은 아니다. 다만 getter를 통해 Collection을 받아온다면, 외부에서 상태값을 변경할 수 있다. 이러한 경우 Collections.unmodifiableList()를 이용하자.

💡 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다

내가 작성했던 코드에서도 불필요한 필드가 존재했다.

public class Host {
	private Lotto winningLotto;
    private List<Integer> winningLottoNumbers;
}

단순히 편하려고 이렇게 작성했던 것으로 기억한다. 필드의 수가 많으면 객체의 복잡도를 높이고, 버그 발생 가능성을 높인다. 필드의 수를 최소화 하자.

💡 테스트 코드도 코드다

리팩터링을 통해 개선해야한다. 반복적으로 하는 부분은 중복되지 않게 한다.

💡 단위 테스트를 할 때 테스트하기 어려운 부분은 분리하고 테스트 가능한 부분을 단위 테스트한다.

메서드의 시그니처를 수정하는 것만으로 테스트하기 좋은 메서드로 만들 수 있다. 테스트하기 어려운 것을 클래스 내부가 아닌 외부로 분리하는 시도를 해 본다.

고민 흔적

기능 목록 작성

4주 차에 들어서니 기능 목록 작성이 훨씬 수월해졌다. 커밋 단위라고 생각하며 기능 목록을 작성하였고, 큰 덩어리를 하나의 기준으로 두고 유의해야 할 세부적인 내용을 하위 항목으로 두었다.

패키지

전체적인 틀은 잡고 프로젝트를 시작하고 싶었다. 패키지를 어떻게 구성해야 할지 고민했다. 요구사항에서 원하는 MVC 패턴을 적용하고 싶었지만 막막했다. 테코톡을 통해 공부하였고, 이 게시글에 정리하였다.

드디어 로직을 구현하는 코드와 UI를 담당하는 로직을 분리해 구현한다.의 의미를 파악했다. 그것은 바로, MVC 패턴에서 View와 Controller의 로직을 분리하라는 의미였다. MVC 패턴을 적용해보면서 시간은 많이 소모되었으나, 구조화 고민하면서 많은 것을 배웠다.

BridgeMaker 와 관련된 코드도 패키지도 이동하고 싶었지만, 요구사항에서 옮겨도 된다는 말이 없어 그대로 두었다. 수정이 가능하다면 controller 패키지로 옮길 것이다.

한편, Spring 프레임워크를 공부할 당시 배웠던 service 패키지가 마음에 걸렸다. controller와의 차이는 무엇일까? controller에 모든 비즈니스 로직을 담으면 클래스가 길어져 한눈에 파악하기 어렵다. 따라서, 비즈니스 로직은 service에 작성하고 controller는 그것을 호출하는 역할을 맡는다.