Portfolio

질문 리스트

타입스크립트를 쓰다보니 data?.value 등을 많이 쓰게 되는데 타입이 string | undefined 식으로 되기 때문에 유틸 함수나 api 함수등에 string, number 등을 지정해놓으면 타입 오류가 나게됨. 이럴때 그냥 data?.value 쓰는 곳에서 data && data.value 쓰는게 나은지, 유틸, api함수의 파라미터의 타입을 유연하게 지정해야 할지 고민입니다

→ (다나)

임의로 data?.value 상태에서 차근차근 리팩토링을 거쳐 타입 좁히기 (Narrowing)을 하는게 낫지 않을까요? 타입을 유연하게 지정하는건 타입스크립트 사용에 대한 의의가 줄어 들 것 같네요! 타입스크립트는 협업에서 명세하는 용도로도 많이 사용되는데, 유연하게 잡으면 동료가 봤을때 이 타입이 어떤 용도인지 보기 어려울 것 같아여!

원래대로라면 data.value 가 없으면 잘못 된 데이터니까! 해당 데이터에 타입을 지정해주고, 내가 원하는 데이터의 property를 가지고 있는지 확인하기 위해 타입 predicator 타입가드를 사용해 볼 수도 있을 것 같아요!

타입 좁히기 문서 두고 감니당… 👀

Documentation - Narrowing

Understand how TypeScript uses JavaScript knowledge to reduce the amount of type syntax in your projects.

https://www.typescriptlang.org/docs/handbook/2/narrowing.html

Documentation - Creating Types from Types

TypeScript's type system is very powerful because it allows expressing types in terms of other types. The simplest form of this idea is generics, we actually have a wide variety of type operators available to use. It's also possible to express types in terms of values that we already have.

https://www.typescriptlang.org/docs/handbook/advanced-types.html

최적화 관련 이슈

구현 완료 후 최적화하는 작업을 진행해보려고 하는데 어떻게 생각하시는지 의견을 듣고 싶습니다!

[현재 진행 상황]

해당 프로젝트를 포트폴리오로 사용하려는 목적

현재 타이트한 일정으로 최적화하기 어려움

[고려하는 방안]

서비스에 필요한 기능을 최대한 빨리 구현한다.

최적화 되지 않은 상태로 코드를 성능 측정한다.

이후 최적화하여 리팩토링

최적화 된 코드 성능 재측정

→ 혹시 최적화 측정하기 좋은 요소 혹은 방법에 대해서도 조언 주시면 감사하겠습니다 🙏

코드의 일관성 관련 이슈

코드의 일관성이 많이 떨어지는 상태인데, 지금이라도 코드 컨벤션을 정해서 리팩토링 하는게 좋을까요?

아니면 프로젝트 기능 구현 후, 리팩토링을 자체 리팩토링을 진행하면서 수정하는게 좋을까요?

[문제가 된 상황]

현재 코드 컨벤션을 스트릭하게 정하지 않은 상태 작업 진행

타입스크립트, 리액트 쿼리에 대한 이해도가 낮은 상태로 시작

→ 타입스크립트 & 리액트 쿼리를 사용했을때 올바른 코드 컨벤션을 정하고 시작할 수 없었음.

지금 코드 컨벤션을 정하는 경우

코드 컨벤션을 결정하는데 걸리는 시간에 대한 우려

→ 코드 스타일에 대한 합의 필요

코드 컨벤션 기준으로 프로젝트에 대한 코드가 전반적으로 리팩토링으로 인한 시간

→ 기능 구현이 우선이 되지 않아도 괜찮을지

에러 핸들링

현재는 파라미터에 의한 에러는 400 에러 코드로 통일해서 메시지가 내려오는데, 이럴 경우 에러 상황 별로 커스텀한 에러 처리를 못해주고 메시지만 띄워주는 처리가 가능할 것 같습니다. 하지만 커스텀한 에러 처리를 위해 410, 411, 412 등등 에러 코드를 만들어가면서 에러 핸들링을 해도 오히려 복잡해질 수도 있을 것 같은데 개발자가 정하기 나름인 부분일까요??

네트워크 에러 핸들링은 어떠한 것을 중점으로 해야할지?

모든 상태코드에 따라 에러 핸들링?

작업에 할당해야 하는 시간

기술 부채로 인해서 오래 걸리는 작업은 어떻게 진행하는게 좋을까요?

(라이브러리를 쓰면 빠르게 해결 가능하지만, 직접 구현하면 오래 걸리는 경우)

(ex) 무한 스크롤 InfiniteScroll 과 같은 라이브러리 사용 / 캘린더 라이브러리 사용

무한 스크롤의 경우 직접 Intersection Observer, throttle 구현하고 useInfiniteQuery 까지 사용하면 구현하는 시간이 지연되고, 얼마나 걸릴지 기한산정이 어려움

라이브러리 구현 이후 → 리팩토링으로 컨버팅하는게 좋은지

마감 기한 산정 이후 → 구현 못했을시 라이브러리 사용

로딩 UI

로딩 인디케이터 그리고 로딩 스켈레톤을 어떠한 상황에서 각각 보여줘야 좋은 사용자 경험일지

멘토님 답변

피그마나 일정 관리 부분에서는 잘되고 있는 것 같아서 특별히 할 말이 없는 것 같다.

시뮬레이터를 통해서 모바일 기종을 실제로 테스트 해볼 수 있으니 한번 생각해봐라(실제 OS, 기종, 모바일 액션 등을 별도로 줄 수 있어서 테스트 해보면 좋을 것이다)

사파리 브라우저의 주소창이 바닥에 있으므로 대응하기 어려움. 실제로 사파리 대응해보면 좋은 경험이 될 것이다(크롬 개발자도구의 모바일 화면은 단순히 화면 비율만 그렇게 됨)

플러팅 버튼 신경 쓰기, 금액 포매팅은 통일시켜서 적용시키기

최종 발표때 데이터를 실제로 넣어서 발표를 해야하고 그 데이터들도 현실에 맞는 데이터들을 넣어놔야 한다. 더 완성도 있어 보이기 위해.

모바일 목적의 페이지 개발이지만 데탑에서 접근하는 경우도 모두 고려해서 UI, UX를 신경써야 한다(데탑에 대한 대응도 시간이 있다면 용인 될 수 있는 정도의 수준까지 대응)

데탑의 max-height는 어느 사이즈를 고려해주면 좋을지?(아이패드 수준의 width, height까지의 크기까지 고려해야함. bootstrap 참고. https://m.getcha.kr/search/0/home)

조금 더 서둘러서 일정을 고려하고 프로젝트 마감 일자도 전날까지 하기 보단 좀 더 앞당겨서 마치도록.

이슈 등록할때 체크리스트를 통해서 자신의 PR 범위, 일정 관리를 관리하는 것이 좋다. 나중가면 귀찮아질 수도 있지만 그래도 최대한 체크리스트를 통해서 관리하는 것이 좋다.

Vercel에서 각자 PR을 올린 것에 대해서 실제로 변경점이 무엇인지, 영향은 없는지 실제로 들어가서 체크해보는 것이 좋다

코드 컨벤션은 추후에 리팩토링때 시간이 너무 오래 걸리지 않을테니 걱정 하지 말고 합의를 맞춰나가는 것만 잘 해나가면 좋을 것 같다

CRA라면 WebVital 써보는 것도 괜찮음 성능 최적화는 추천하지만 성능이 극적으로 좋아지진 않을 가능성이 크니까 기대는 크게 하지는 않기(React에서 애초에 최적화를 많이 해줄 것이다) 성능측정은 lighthouse 를 통해서 진행하고 안좋은 지표들을 개선하는 쪽으로 진행하면 매우 좋을 것 같다

크롬 개발자도구의 Performance insights 한번 해보기(lighthouse 의 지표들을 보기 편하게 보여줌) → 이 모든 것이 익숙해지면 크롬 개발자도구의 ‘성능’ 탭을 봐야 함

→ webpagetest.org(web performance test)는 클라우드 서버가 어디 나라 어느 속도에 따라서 lighthouse 지표가 달라지는지를 볼 수 있다. 정말 참고만 하는 느낌. 지금 알기엔 너무 어려운 부분.

일정 밀리는 사람이 있을 수 밖에 없을텐데 너무 스트레스 받아하지 말고, 일정이 먼저 끝나는 사람들은 QA를 하거나 다른 사람들의 작업을 가져가는 것도 좋을 것 같다. QA같은 것은 리스트로 만들어 보는 것도 좋을 것 같다

팀 10 프론트엔드 중간 피드백 면담