Skip to main content

FE 개발단계 체크 리스트

Process​

  • 1.Requirements
  • 2.Develop
  • 3.Testing
  • 4.Monitoring Plan

1.Requirements & System Design​

📌 1.기존의 스펙과 코드를 이해하는 단계

일정이 촉박하다고 반드시 이 단계를 넘어가지 마세요.! 일정의 일부입니다.

  • 다른 사람들의 짠 코드의 로직을 이해 해야함(익숙도)

    • 아무리 잘 짠 코드라도, 간단한 코드라도 남이 짠 코드를 바탕으로 무언가를 만들려고 하면 복잡하다.
    • 그래서 다른 사람들의 코드를 마치 내가 짠 코드 처럼 익숙해지는 단계가 필요하다.

  • 사용중인 API 목록(API Spec) 파악

    • 데이터의 확실한 정의를 리체크 해라.
    • 특히나 거지같은 변수명으로 함부로 의미를 추론하지 마라.

  • 놓치기 쉬운 FE 로직들

    • Ingress Point 정리 ( 외부에서 들어오는 경로들, 심지어 외부 사이트도 있을 수 있음. )
    • 데이터 차원 정리 ( Retail로 접속 or 3P로 접속 등 )

📌 2.요구사항 수집 단계 및 준비

  • PRD에서 꼼꼼히 테스트 케이스들을 작성하는 훈련을 먼저 해야한다.

📌 3.커뮤니케이션

  • API Interface는 미리 공유 및 제안을 하자.
    • 변수명, 내부 로직, 단위 체크, 의미 체크, Nullable 체크

2.Develop​

📌 1. 시스템 도구 활용하기

  • i18n을 JSON으로 변경하는 도구 사용하기
    • *400개 한/영 옮기면 800번이나 왔다갔다 해야 한다. 실수안할 자신이 있는가? 나는 96% 정확도를 가진다.

📌 2. API Interface Testing

  • 데이터 정합성 : 데이터 포인트가 많으면 필드명이 헷갈려서 엉뚱한 필드를 쓰는 경우가 허다하다. 반드시 올바른 데이터가 나오는지 테스트

📌 3. UI LifeCycle Testing

  • 컴포넌트 라이프 싸이클
    • 팝오버
      • 생성 단계 : 기존의 데이터들이 초기화, 새롭게 패칭.
      • Loading & Error
        • 적절한 Status UX (업다면 제안)
      • Render :
        • 레이아웃 쉬프팅 체크.
        • 과도한 리렌더링 체크.
      • Rerendeing
        • 메모이제이션 의존성 배열에 놓친것
      • Submitting
        • 사용자의 중복 제출을 막아라
      • 소멸
        • 스토어 클린업
        • 이벤트 리스너 등 이펙트 클린업
        • API 요청 Abort
    • 페이지 수준에서도 마챤가지다.

📌 4. UI Stress Testing

  • 포멧팅, 임계값(String(i18n), Number), 반응형 레이아웃
  • 화면 해상도에 따라 컴포넌트가 줄어들면 어떻게 되는가? > 개행, 줄임표 등 대응
    • 예) min-width ~ context-fit ~ max-width 의 범위를 넘어가면, wrap으로 개행 처리.
    • 최후의 수단으로 언어별, 숫자별 UI의 마크업을 달리한다. 혹은 font-size 등의 CSS를 달리한다.

📌 5. 컴포넌트 하위 호환성 고려하기

  • UI컴포넌트는 많은 곳에서 참조된다. 하위호환성을 지키면서 개발을 해야 한다.

📌 전역, 지역, 서버 상태관리

  • (공통) 리렌더링이 되는 컴포넌트라면 초기화, CleanUp 싸이클이 언제 필요한가?
  • (공통) 재생성 되는 컴포넌트라면 초기화, CleanUp 싸이클이 언제 필요한가?
  • 재생성 로직만으로 싸이클을 다룰 수 있는가?

📌 Validator 순서 스펙 명시하기

  • 유효성 검사 조건, 노출 순서, 노출 조건 확인

📌 의존성 체크

  • 컴포넌트 수정은 항상 하위 호환성을 고려한다. 사이드 이펙트를 방지
  • 프로덕션과 동일한 MFE의 환경 테스트 : 스타일이 깨지는 경우도 있음

2.4 Unit Test​

📌 필수 단위 테스트 코드 작성

  • 그래프, 수치에 대한 함수는 테스트 코드를 반드시 작성한다. 예를들어 계산식, 선형보간법, 특정 공식 구현, 주요 비즈니스 로직

3.Testing​

📌 훈련

  • PRD에서 꼼꼼히 테스트 케이스들을 작성하는 훈련을 먼저 해야한다

📌 Validator 순서 Testing
📌 UI Stress Testing
📌 UI LifeCycle Testing

4.Monitoring​

📌 시스템 이상탐지 & 얼럿

  • BFF : Grafana 대시보드에 특정 피처들만 집중해서 모아둔 대시보드와 얼럿을 설정해야 한다.
  • FE : Sentry 로깅 모니터링과 얼럿을 만들어야 한다.

회고​

Action Item

1.모든 상태의 합집합은 전체 집합인지 체크하자.

  • 1.그래프에 데이터가 없는 케이스 고려 = 상승 | 하락 | 동일 | 없음
  • 2.상품 목록 API 처리 = 로딩중 | 상품없음 | 상품 리스트 | 오류

2.시스템 예외사항은 - window.Alert 대신에 별도의 Modal UI 요청하자.

3.State가 복잡한 경우에는, 다양한 케이스를 고려해야 한다.

  • 메인Filter, 서브 Filter, Sorter, Pagination, Selection 등 다양한 인터렉션이 존재한다. 각각의 로직에 잘 대응하는것이 필요.
  • PageSize가 10일때는 50Page가 있지만, PageSize가 50일때는 50번째 페이지는 없다. 적절하게 마지막 페이지로 이동해야 함.
  • 메인 필터에 따라서, 서브 필터에 상품군의 갯수가 달라진다. 모수가 바뀌는것 대응

4.CSS 조금이라도 이상한가 꼼꼼해 봐야 한다.

  • Padding/줄간격 / i18n 텍스트 깨짐 / CommaInsert
  • ⬆️ 이모지는 쓰면안된다.