동영 멘토님 피드백
프로젝트 주제
문제 의식으로 시작하는 배경과 이어지는 해결을 위한 접근법까지는 좋아 보여요. 다만, 프로젝트에 핵심 기능으로 제시된 기능들을 봤을 때 '과연 이 기능들로 앞에서 제시한 문제를 해결할 수 있을까?'라는 의문이 듭니다.
- 루틴을 관리할 수 있고
- 루틴을 공유하는
- 커뮤니티 서비스
가 있다면 사용자들은 반복되는 일상 속 루틴에 즐거움을 느끼고 노잼 시기에서 벗어날 수 있을까요?
요컨대 제가 봤을 땐 제시한 핵심 기능이 정의한 문제에 미치지 못하는 느낌입니다. 이 경우엔 제시한 문제 의식을 축소하거나, 개발할 기능을 문제 정의 수준으로 끌어올려서 서비스의 정체성을 확실히 해주면 좋을 것 같습니다.
Git
커밋 메시지도 양호하고, Issue와 PR 관리도 전체적으로 잘 진행되고 있는 걸로 보여서 지금처럼 계속 사용하시면 좋을 것 같아요. 전체 코드를 다 보는 건 힘들어서 몇몇 파일만 뒤져보다가 눈에 띈 부분이 있어서 몇 가지만 코멘트 남깁니다.
- 현재 사용하고 있는 라이브러리 중에서
moment를 의존성으로 들고 있는 패키지가 있나요? moment는 2020년 deprecated 되었고, 더는 개발되지 않는 프로젝트라 moment를 사용하던 패키지들도 호환성은 유지하되 다른 날짜 관련 라이브러리를 사용하도록 권장하는 추세이므로 새로 개발하는 서비스라면 moment 대신 다른 라이브러리를 선택하는게 좋을 것 같습니다.
eslintrc파일이 있는데package.json에도eslintConfig키가 포함되어 있네요. 내부 우선 순위에 따라 설정 파일은 하나만 사용하게 되니 한 가지 방식을 선택해서 통합하시기 바랍니다.
- 타입스크립트를 사용한다면 객체 고정 시
Object.freeze대신const assertion문법을 사용할 수 있습니다. 이 편이 타입 추론에 있어서 더 큰 이점이 있습니다.
질문 답변
타입스크립트로 리액트 개발을 하면서 dom관련 타입에 막힐 때 어떤식으로 해결해야할지 궁금하다. 타입의 문서를 어떻게 뜯어보시는지? 혹은 어떻게 검색을 하시는지? 좋은 자료나 팁이 있으신지 궁금하다.
주로 막히는 문제가 어떤 건지 구체적인 예시가 있다면 더욱 자세한 답변을 드릴 수 있을 것 같긴 하네요. 일단 DOM 타입은 대부분 MDN Web API의 인터페이스와 매칭되기 때문에 DOM 타입을 볼 때는 MDN을 찾아보거나, 에디터에서 자동으로 찾아주는 lib.dom.d.ts 파일을 보는 편입니다.
리액트에서 타입스크립트를 적용하는 실용 예제는 React TypeScript Cheatsheets 저장소에 잘 정리되어 있습니다.
현재 작성한 코드들에 대해서 타입을 맞게 명시한건지, 타입스크립트를 잘 사용하고 있는지 궁금하다. 타입스크립트는 어떤 식으로 공부해야하는지 꿀팁 같은 것도 궁금하다ㅎㅎ 있을지는 모르겠지만...
극단적인 방법(?)일 수도 있긴 한데, 저는 타입스크립트를 처음 사용할 때 tsconfig 파일에서 strict 옵션을 모두 활성화해서 사용했습니다. '지킬 수밖에 없는 상황'을 만들었달까, 잘 알려진 lint 세팅 등을 도입해보면 어느 정도 good practice에 대한 감을 잡을 수 있지 않을까 싶습니다.
사실 제가 생각하는 가장 좋은 학습은 '스스로 필요성을 느끼는 학습'이기 때문에, 언젠가 타입스크립트를 사용할 때 '자바스크립트보다는 타입스크립트가 편해'라는 생각이 든다면 잘 사용하고 있는 게 아닐까 싶습니다.
타입스크립트에서 타입 문제가 발생했을 때 해결이 되지 않으면 "any" 타입을 사용해도 될까요? 프로젝트를 진행할 때 일단 동작하게 만드는 것이 먼저인지, 깔끔하게 필요한 코드만 작성되어 효율성이 높은 코드를 만드는 것이 먼저인지 궁금합니다.
정 해결이 안 되는 상황이라면 불가피하게
any를 사용할 수도 있겠지만, any를 사용하면 사실상 타입스크립트를 사용하는 의미가 희석되기 때문에 any는 가능한 한 사용하지 않는게 좋습니다. 저는 any는 사용하지 않고, 타입이 확정되지 않아서 지정할 수 없는 경우 unknown 등의 타입을 활용하는 편입니다.타입 정의가 힘들다면 정의하려는 타입이 정의하기에 적절한 타입인지 고려해보는 것도 좋습니다. (객체의 변동성이 너무 높다거나 광의적인 내용을 포함하고 있다면 종종 그런 경우도 있습니다.)
- 프로젝트를 진행할 때 일단 동작하게 만드는 것이 먼저
- 깔끔하게 필요한 코드만 작성되어 효율성이 높은 코드를 만드는 것이 먼저
1, 2는 트레이드오프 관계라서 속도와 퀄리티 사이에서 적당한 타협이 필요한 부분입니다. 일단 코드는 작동을 전제로 작성되어야 하기에 퀄리티를 따지는 것보다는 속도가 우선이긴 합니다.
다만, 위 예시를 가져와서 바쁘다는 이유로 모든 타입을
any로 지정할 것 같으면 굳이 타입스크립트를 사용할 이유가 없으므로 타입스크립트를 사용한다면 '타입스크립트를 사용해서 얻을 수 있는 최소한의 퀄리티는 유지할 수 있도록 한다'가 판단 기준 중 하나가 될 수 있겠네요.