멤버십 과정 세 번째 주가 마무리 되었습니다. 🥳

저번주에 언급했던 것 처럼 이번주 부터는 멘토님의 코드리뷰가 시작되었는데, 저희 그룹을 담당해주신 멘토님이 타입스크립트에 대한 경험이 많으셨습니다.

코드리뷰에서 제가 활용하던 타입스크립트에서 몇 가지 주의할 점을 짚어주셨고 덕분에 큰 도움이 되었어요!

이러한 부분들을 같이 확인해보면 좋을 것 같습니다.

타입스크립트에서의 인터페이스

저 같은 경우는 백엔드를 설계할 때 여러 프레임워크들의 장점들을 뽑아 구성해보려고 했었습니다.

그 중 실제 데이터에 접근이 필요한 부분을 Spring data를 참고하여 저장소 패턴(Repository Pattern) 을 적용하였습니다.

저장소 패턴은 객체지향 설계에서 도메인 모델(핵심 비즈니스 로직) 과 데이터 소스 사이의 추상화를 통해 비즈니스 로직과 실제 데이터 저장 처리의 관심사를 분리하는 패턴입니다.

사실 이 자체는 문제가 없었지만 이를 활용하기 위한 코드에 약간의 문제가 있었습니다.

인터페이스를 구현하도록 하여 서비스 로직에서 활용하도록 했는데, 제가 작성한 코드를 게시글을 의미하는 Post로 바꾸어 확인해보면 아래와 같습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

interface Post {
  id: string,
  title: string,
  content: string,
  createdAt: Date,
  updatedAt: Date,
}

interface PostRepository {
  findById(id: string): Promise<Post | null>;
}

class PostDummyRepository {
  constructor(
    private readonly data: Post[]
  ) {
  }

  async findById(id: string): Promise<Post> {
    return this.data.find(post => post.id === id) ?? null;
  }
}

class PostService {
  constructor(
    private readonly postRepository: PostRepository
  ) {}
  
  async findPost(id: string) {
    const post = await this.postRepository.findById(id);
    
    if (post === null) {
      throw new Error(`${id}에 해당하는 글이 없습니다.`)
    }
    
    return post;
  }
  /* ... */ 
}

언뜻 보면 나쁘지 않아 보이죠? 멘토님은 아래와 같은 코멘트를 남겨주셨어요.

이 인터페이스가 타입스크립트 개발 느낌보다는 자바로 개발을 하는거 같다는 느낌을 많이 주네요
타입스크립트에서 이런 인터페이스는 어떤 의미를 가지게 될까요?

그래서 왜 이런 코멘트를 남기셨을까 고민해본결과는 바로 덕 타이핑이었습니다.

덕 타이핑

덕 타이핑(duck typing)은 동적 타이핑의 한 종류로, 객체의 변수 및 메소드의 집합이 객체의 타입을 결정하는 것을 의미합니다. 아래와 같은 문구는 한번 쯤 들어보셨을거에요

만약 어떤 새가 오리처럼 걷고, 헤엄치고, 꽥꽥거리는 소리를 낸다면 나는 그 새를 오리라고 부를 것이다.

타입스크립트도 타입을 덕 타이핑으로 타입을 처리합니다. 그렇다면 제가 작성한 코드는 어떠한 문제가 있었던걸까요? 새로운 예시를 한번 보겠습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

interface Comment {
  id: string,
  postId: string,
  title: string,
  content: string,
  createdAt: Date,
  updatedAt: Date,
}

interface CommentRepository {
  findById(id: string): Promise<Comment | null>;
  findByPostId(postId: string): Promise<Comment[]>;
}

class CommentDummyRepository {
  constructor(
    private readonly data: Post[]
  ) {
  }

  async findById(id: string): Promise<Comment> {
    return this.data.find(comment => comment.id === id) ?? null;
  }
  
  async findByPostId(postId: string): Promise<Comment[]> {
    return this.data.filter(comment => comment.postId === postId);
  }
}

위처럼 Comment라는 도메인 모델이 있다고 가정해보면 아래와 같은 코드는 오류를 발생시키지 않습니다.

1
2
3

const data: Comment[] = [];
const repository = new CommentDummyRepository(data);
const service = new PostService(repository);

이게 바로 덕 타이핑 덕뿐인데요, PostRepository가 요구하는 구성 요소들을 CommentDummyRepository가 모두 포함하고 있고, 반환값으로 사용되는 Comment도 Post가 요구하는 구성 요소들을 모두 포함하고 있기 때문에 CommentDummyRepository를 PostRepository로 보는것이죠

멘토님이 자바같다고 하신 이유도, 자바였다면 전혀 문제가 없을 코드였기 때문이었겠죠?

그래서 제가 생각한 근본적인 문제는 인터페이스에 선언된 메소드가 충분히 서술적이지 않은 것이 문제였던 것이었습니다.

엔티티는 어쩔수없다고 하더라도 리포지토리 인터페이스는 아래와 같이 만든다면 문제를 충분히 예방할 수 있을 것으로 보입니다.

1
2
3
4
5
6
7
8

interface PostRepository {
  findPostById(id: string): Promise<Post | null>;
}

interface CommentRepository {
  findCommentById(id: string): Promise<Comment | null>;
  findCommentsByPostId(postId: string): Promise<Comment[]>;
}

no-return-await

ESLint에서 제공하는 규칙 중 하나인 no-return-await는 코드에서 return await을 사용하는 것을 금지하는 규칙입니다. 저는 사실 아래 예시처럼 await를 쓰고 있었어요

1
2
3

async function example() {
  return await someAsyncFunction();
}

저렇게 return await를 하지 않으면 Promise<Promise<??>> 형식으로 반환될 것이라고 생각했었기 때문인데요..😅

async 함수는 자동으로 Promise를 반환하므로, await 없이도 Promise가 제대로 처리되는걸 이제야 알았습니다. 그래서 아래와 같은 코드도 동일하게 처리됩니다.

1
2
3

async function example() {
  return someAsyncFunction();
}

return await는 일반적으로 추가적인 Promise 처리 단계를 유발하기 때문에 사용하지 않는 걸 권하고 있었습니다.

아래와 같은 경우는 return await가 필요한 경우입니다.

1
2
3
4
5
6
7
8

async function example() {
  try {
    return await someAsyncFunction();
  } catch (error) {
    console.error('Error occurred:', error);
    throw error;
  }
}

위와 같은 경우는 await return을 하지 않으면, 로직 실행이 비동기로 처리되기때문에 try...catch 블록 내에서 에러가 발생할 때 의도대로 처리되지 않습니다.

타입 추론

타입 추론(Type Inference)은 개발자가 명시적으로 타입을 지정하지 않아도 타입스크립트 컴파일러가 변수나 표현식의 타입을 자동으로 추론하는 것을 의미합니다.

사실 타입스크립트 뿐만 아니라 Go, Kotlin 같은 언어에서도 제공합니다.

매주 금요일 진행되는 마스터 세션에서는 지원자의 코드를 마스터님이 직접 리뷰해주시는데, 그때 나왔던 주제 중 하나였어요

결론은 타입을 적게 쓸수록 좋다. 였습니다.

개인적으로 찾아보니 타입 추론을 잘 활용하면 아래와 같은 장점이 있다고 합니다.

• 코드 간결성
• 개발 생산성 향상
  • 개발자가 타입을 일일이 지정하는 수고를 덜 수 있다.

조금 더 생각해보니 타입 추론이 잘 이루어지는 코드들은 처리해야할 작업의 시작, 끝 정도만 타입을 명시적으로 지정해도 잘 동작하는 코드이더군요

그래서 사실 본체는 타입 추론이 잘 되는 코드를 작성하는 것이 세부사항에 대한 설계, 관심사 분리나 기능 분리가 잘 된 코드였던게 아닐까 싶습니다.

아직 확신은 없지만 타입 추론을 최대한 활용하는 방식으로 구현을 해봐야할 것 같아요 🤣

의견과 모르는 것

이번 주 그룹 회고에서 한 캠퍼분이 본인의 아쉬운 점으로 아래와 같은 이야기를 하셨습니다.

다른 분들의 질문에 대해 잘 몰라서 많은 답변을 해드릴 수 없었던 부분이 아쉬웠어요

그래서 저는 아래와 같은 답변을 드렸어요

꼭 알아야만 답변을 할 수 있는걸까요?
답변이 맞고 틀리고는 상관 없이 의견 자체를 공유하는 것이 중요한 것 아닐까요?

돌이켜보면 저도 이런 고민들을 많이 했던 것 같고, 지금도 조금은 하고 있는 것 같아요.

뭔가 나의 의견이 정답이 아니었으면 큰 잘못을 한 것 같고, 내 답변이 하찮아서 도움이 안되면 창피하기도 하고, 등등 이런 생각들을 주로 했던 것 같습니다.

그런데 시간이 지나면서 이런 생각들을 많이 하지 않게된 것 같아요

그러한 첫 번째 이유로 실제 일을 해보면서 이미 널리 알려진 방법들이 내가 풀어야하는 문제에 딱 들어맞는 경우는 많이 없었던 것 같습니다.(그래서 어려운 것 이겠지만요 ㅎㅎ)

그래서 정답에 대한 의견은 거의 들을 수 없었을 뿐더러, 방향성이나 문제에 대한 의견을 많이 들었을 때 그 상황에서 할 수 있는 최선의 선택을 찾을 수 있었던 것 같아요

두 번째 이유로는 개발자는 결국 문제를 해결하는 사람이라는 점 인 것 같습니다.

어떠한 문제를 해결하려고 할 때 다른 사람들이 같은 문제를 어떻게 해석하는지, 어떤 부분들을 중요하게 생각하는지 와 같은 생각들을 들었을 때 실제로 저의 문제를 바라보는 시야라던가, 문제를 해석하는 근본적인 역량이 향상된다고 느껴졌었기 때문이에요

그래서 저는 다른 사람들이 어떠한 문제에 대해 질문 했을 때, 제가 생각할 수 있는 모든 것을 다 동원해서 같이 고민해주고 있는 것 같아요, 그 사람이 저의 관점을 어떻게 해석하는지도 너무 궁금하거든요

그래서 결론은 개인의 의견은 너무나도 소중하고 값진 것 이니까 서로 많이 공유해요 였네요😄

마무리

아직 멘토님의 피드백을 모두 반영하지 못했는데 다음주는 더욱 더 바쁠 것 같습니다.

다음주까지 끝나면 첫번째 개인 프로젝트가 끝나고 인터미션기간이 주어진다고해요

이번 주는 할일이 많이 남은 만큼 열심히 불태우고 인터미션 기간에 푹 쉬어야겠습니다.

한 주 모두 고생 많으셨습니다🔥