[저작 도구 만들기] 3 ~ 5주차 진행 사항 (2024.12.16 ~ 2025.01.05)

회고 😪

작업 진행 내용 정리 및 회고를 위해서 매주마다 진행사항을 블로그에 올리고 하였으나, 생각보다 진도가 원한는만큼 나가지도 못했고 그리고 살짝 귀찮은 것도 있었다. 갑자기 1월이 되면서 시간을 더 내기가 힘들어 더 미루게 되었다.

 

이제는 다시 시작해야겠다는 생각이 들어 마지막 작업 내용이었던 3 ~ 5주차 진행을 올리게 되었다.

 

 

🎮 작업

• 기존 작업했었던 모델, 컴포넌트, 프로퍼티, 매니저의 구조를 변경하였다.
  • 처음 설계와 실제 구현간의 맞지 않는 부분을 수정하였다.
• 위치, 사이즈와 관련 된 프로퍼티 기능을 구현하였다.
• 네모 모양의 기본 컴포넌트를 구현하고 프로퍼티와의 연관관계를 설정하였다.

 

🤔 고민

설계

코드 작업 전 설계했었던 부분이 실제 코드 작업을 해보면서 누락된 부분도 많고, 코드 구현과 맞지 않던 부분도 많았다. 예로 모델과 엘리먼트의 관계는 모델에서 엘리먼트에게 메시지를 단방향으로 전송하는 관계를 설정하였다.

 

하지만 코드구현이 진행되면서 엘리먼트에서 발생한 변경점을 모델로 전송해야하는 경우도 존재한다는 걸 깨달았다. 이 부분까지는 고려하지 못했던 것이다. 그래서 이 부분을 어떻게 설계해야할지 고민이다. 모델과 엘리먼트 사이에 각각의 인터페이스를 두고 양방향으로 메시지를 주고 받도록 할 것인지, 아니면 다른 방법이 있을 지 고민해봐야할 것 같다.

 

시간

처음 생각했던 것보다 시간이 너무 많이 지체되고 있다. 일주일에 이 프로젝트에 투입할 수 있는 시간이 적기도하고, 기존 설계가 맞지 않아 리팩토링하는 시간이 너무 많이 시간이 들다보니 진도가 나가지 않는다. 그러다보니 의욕도 살짝 떨어지는 것 같다.

 

이부분은 맞지 않는 부분이 있다면 메모만 일단 해놓고 빠르게 기능을 완성 하면서 추후 리팩토링하는 과정으로 방향을 바꿔야 할 것 같다.

 

 

📖 배운 점

메서드에서 타입 정의

이전 자바를 했었던 기억때문에 제네릭을 정의할때 클래스에서만 하려고 했었다. 하지만 타입 체크가 클래스 생성시점이 아닌 메서드 호출 시점에 해야하는 경우도 존재하였다. 고정관념으로 인해 클래스에 정의한 제네릭으로만 활용하려고 하다보니 타입이 점점 더 복잡해지고 해결이 잘 되지 않았다.

메서드 호출 시점에 타입 체크를 해야하는 경우에는 메서드에서 제네릭을 따로 정의하는 것도 고려해보자.

 

 

⭐️어려웠던 점

타입스크립트

이번에 제네릭을 활용한 타입을 정의해보면서 아직까지 타입스크립트가 많이 부족하다는 것을 깨닫게 되었다. 클래스로 상속을 구현하면서 각 클래스에 제네릭을 사용하였다. 제네릭으로 너무 많은 관계가 얽혀 유연성도 떨어지고 복잡하게 되었다.

 

 

형식에 할당할 수 없습니다 / 제약 조건의 다른 하위 형식으로 인스턴스화할 수 있습니다

이번에 진행하면서 가장 많이 본 오류이면서 이 기간동안 가장많은 시간을 보내게 한 오류이다.

 

추상 클래스에서 제네릭을 사용하였다. 추상 클래스의 일반메서드에서 파라미터로 제네릭 타입을 받는 메서드를 호출하였다. 추상클래스를 상속하는 클래스에서는 정상적으로 작동하는 것은 확인하였다. 하지만 추상 클래스의 메서드에서는 타입이 맞지 않다고 나오며 실행이 되지 않았다. 이 부분도 복잡한 상속과 제네릭을 남용과 타입 정의를 제대로 하지 않아 발생한 것으로만 추측하고 있다.

 

해결은 호출받는 메서드에 클래스의 제네릭을 활용하지 않고 별도로 타입을 정의하여 해결은 하였다. 정확히 원인을 모르기 때문에 좀 더 고민해 봐야 할 것 같다.

 

 

디자인 패턴

어떤 상황에서 패턴을 써야하고 패턴을 구현하기 위한 구조를 더 명확하게 잡을 필요가 있을 것 같다. 인터넷에 대략적인 이론에 대해서만 공부하고 실제 테스트 해보지 않고 적용하다보니 올바르게 사용하지 않아 결국 나중에 리팩토링 하는데 시간을 많이 보내게 되었다.

 

 

📚 정리

• 타입스크립트 공부를 하자.
• 디자인패턴 공부를 하자.
• 회고는 주간 단위가 아니라 스프린트 단위로 하는게 의미있을 것 같다.