[RPG 개발] 20일차

참고: 이 일지는 네이버 카페로부터 옮겨진 레거시 게시물입니다.

 

원래 새 콘텐츠를 만들려고 했습니다. 비록 어제 3개의 아이템을 더 추가했지만 겨우 포션과 잡탬이였기 때문이죠. 가장 중요한 방어구와 액세서리 추가와 관련 시스템을 만들려 했지만 그전에 코드를 어떻게든 개선했어야 했습니다. 사방에 any와 as가 널려있어 익셉션 터지는걸 조잡하게 막아놓고 어떤 건 심지어 unknown으로 형 변환해서 원하는 인터페이스로 다시 형 변환을 했습니다. 여기서 콘텐츠를 늘리면 언젠가 큰 뇌진탕이 올 것을 직감했고, 이전에 들었던 eslint를 알아봤습니다.

eslint의 규모는 생각보다 너무나도 컸습니다. 설정 파일을 통해 확장 패키지를 설정할 수도 있었고, 규칙을 커스터마이징할 수도 있었습니다. 이걸 알아보다가 prettier에도 설정 파일이 존재한단 걸 알았네요. 처음 초기화를 하여 설정 파일이 생성되고 eslint./src를 통해 소스코드 내 모든 코드를 검사해보면

뭔가가 굉장히 잘못됨을 느꼈습니다. 원치 않은 규칙들을 모두 주의 단계나 무시 단계로 내린 다음, 내가 개선할 필요가 있다고 생각한 에러들은 직접 해결했습니다. 이때 namespace를 쓰지 말란 경고가 등장하자 왜 그런지 알기 위해 namespace를 다시 알아보니 두 라이브러리의 이름이 겹치는 걸 막기 위함이란 걸 알게 되었습니다. 전 rpg의 규모가 초대형 프로젝트까지 커지기엔 오랜 시간이 걸릴 것이고, 그게 아니더라도 이름이 중복되면 as를 사용할 수도 있으므로 쓸 필요가 없다고 판단해 대부분의 모듈에서 namespace를 제외했습니다.

추상 선언된 메소드의 매개변수가 미사용 변수 경고에 걸리자 이리저리 삽질을 했는데,

플러그인이 원본 규칙을 덮어씌우는 게 아니라 오히려 덮어씌워져 타입 스크립트 규칙이 무시되던 해프닝도 존재했습니다.

​

오늘 SOLID원칙을 다시 읽어보며 단일 책임과 확장성에 대한 구조 개선을 시작했습니다.

getOne 함수는 그 효과를 제대로 본 케이스입니다. Rationess 인터페이스를 사용한 클래스의 인스턴스의 배열을 넣으면 특정 비율에 따라 랜덤 하게 배열 중 하나가 나옵니다. 이전엔 두 번째 문자열 인자로 인스턴스에 참조하여 비율 값을 얻어냈는데 이를 통해 비율 변수에 의존적이지 않게 되었습니다. 이전엔 인스턴스의 비율 변수의 이름이 바뀌면 두 번째 인수를 일일이 바꿔야 했지만 이젠 그것들의 이름이 바뀌던 값이 바뀌던 getRatio()만 구현이 된다면 getOne이 바뀔 리는 없으니깐요.

​

저런 좋은 효과가 존재했더라면 아직까지 해결 못한 문제들도 있습니다.

앞서 getOne 함수에 대해 설명드렸다시피 이 함수는 Rationess 인터페이스를 상속한 인스턴스들 중 하나를 뽑아옵니다. 그리고 Item은 Rationess를 상속하기 때문에 getOne(Contents.Items.getItems()); 자체는 전혀 문제가 없습니다.

문제는 그리해서 얻은 아이템이 Durable를 상속한 상태여야 하는데 그렇지 않다는 점입니다.

결국 getOne에 Durable 인터페이스를 상속하는 아이템 배열을 넣어야 합니다. 하지만 대체 어떻게 아이템 배열에서 Durable 인터페이스를 상속한 아이템만을 필터링할 수 있을까요? 다른 언어라면 instanceof 연산자로 인터페이스의 상속 여부를 확인할 수 있지만 그건

타입스크립트에선 불가능합니다.

추측상 타입스크립트의 인터페이스는 다른 언어와 달리 타입(형식) 정의만 하는 것 같아 instanceof로 사용할 수 없는 것 같습니다. 이걸 해결하려면 인터페이스를 추상 클래스로 바꿔야 하지만 이러면 solid 원칙을 어기는 게 아닐까라는 생각이 듭니다. 그렇지만 추상 클래스에서 인터페이스처럼 추상 메서드만 정의한다면 인터페이스와 다름없지 않아 원칙을 지킨 셈이지 아닐까요?