프론트엔드 엔지니어링은(는) 무엇을 하나요?
카피, 주석 또는 보고서를 작성하기 전에 anti-ai-writing을 읽으십시오. 저장소 지침, 기존 화면 및 컴포넌트, 디자인 토큰, 프레임워크/의존성 버전, 라우팅, 데이터 계약, 테스트 규칙을 읽으십시오. 기존 스택과 유틸리티를 사용하고, 익숙하지 않은 API는 해당 버전의 공식 문서에서 확인하십시오. 관련 없는 작업과 기존 제품 동작은 유지하십시오.
화면의 역할과 디자인 확립
대상 사용자, 사용자 작업, 주요 동작, 콘텐츠 계층, 필요한 상태, 수락 기준을 식별하십시오. 제공된 디자인과 기존 제품 패턴을 먼저 사용하십시오. 새로운 대규모 인터페이스의 경우, 누락된 중요 요구 사항을 명확히 하고 계획이 도움이 될 때 agent-planning을 사용하십시오. 이해된 작은 변경에는 디자인 회의를 요구하지 마십시오.
새로운 시각적 방향이 필요한 경우, 관련 참고 자료를 연구하고 유용한 계층 구조, 밀도, 내비게이션 및 상호작용 원칙을 제품의 언어로 변환하십시오. 독점 브랜딩, 텍스트, 에셋 또는 정확한 레이아웃을 복사하지 마십시오. 하나의 화면을 위해 전체 디자인 시스템을 발명하지 않고 구현을 안내할 수 있을 만큼의 디자인 결정을 기록하십시오.
프로젝트 토큰에서 일관된 타이포그래피, 간격, 색상, 반경 및 강조를 사용하십시오. 일반적인 히어로 섹션, 균일한 카드, 과도한 간격 또는 장식적 그라데이션 대신 사용자의 동작과 정보를 우선시하십시오. 이러한 패턴은 제품이 요구할 때 적절할 수 있습니다. 미학적 금지를 강요하지 마십시오. 긴 레이블, 드문 데이터 및 빽빽한 데이터를 포함한 현실적인 콘텐츠를 사용하십시오. 제품 카피에서 관련 없는 구현 세부 사항을 제거하십시오. 노출된 모든 컨트롤을 기능적으로 유지하거나 사용할 수 없는 것으로 명확히 표시하십시오. 자리 표시자를 작동 기능으로 위장하지 마십시오.
명확한 컴포넌트와 상태 구현
변경된 프론트엔드/백엔드 계약의 경우 api-design을 사용하고 지원되는 소비자를 유지하십시오. UI 픽스처에서 백엔드 계약을 추론하지 마십시오.
집중된 책임과 정당화된 추상화를 위해 writing-clean-simple-code를 사용하십시오. 관련 없는 플래그의 큰 행렬보다는 컴포지션과 기존 컴포넌트 API를 선호하십시오. 임의의 줄 수가 아니라 책임에 따라 분할하십시오. 모든 컴포넌트에 대해 별도의 컨테이너나 훅을 강제하지 않고 데이터와 프레젠테이션 소유권을 명확히 유지하십시오.
상태가 소유된 위치에 배치하십시오: 로컬 상호작용 상태, 공유 상태, 탐색 가능/공유 가능한 뷰를 위한 URL 상태, 원격 데이터를 위한 기존 서버 상태 도구. 중복된 파생 상태와 모순되는 부울을 피하십시오. 몇 개의 props를 피하기 위해 전역 스토어를 도입하지 마십시오. 관련된 경우 안정적인 항목 식별, 기록 탐색, 딥 링크, 프레임워크 렌더링/하이드레이션 계약을 유지하십시오.
로딩, 빈, 성공, 오류, 비활성화, 보류 중, 권한 상태를 적절히 처리하십시오. 데이터 없음과 필터링된 결과를 구별하십시오. 복구 가능한 오류 후 입력된 데이터를 보존하고, 진행 방법을 설명하며, 중복 제출을 방지하십시오. 낙관적 업데이트의 경우 실패, 동시 변경, 오래된 응답 및 조정을 고려하십시오. 공유 요청을 취소하기 전에 취소 소유권을 추적하십시오. 숨겨진 컨트롤을 권한 부여로 사용하지 마십시오. 서버 측 시행은 여전히 필요합니다.
레이아웃과 상호작용을 포괄적으로 만들기
접근성 및 반응형 검사를 읽으십시오. 기본 시맨틱 HTML과 검증된 접근성 기본 요소를 선호하십시오. 사용자 정의 상호작용은 완전한 키보드, 포커스 및 상태 계약을 구현해야 합니다. 레이블, 오류 및 상태 피드백은 색상이나 애니메이션에 의존하지 않고 이해할 수 있어야 합니다.
콘텐츠가 필요한 지점에서 중단점을 선택하고 기존 레이아웃 토큰을 존중하십시오. 유연한 레이아웃, 적절한 너비 제한 및 반응형 에셋을 사용하십시오. 좁은 뷰와 넓은 뷰, 확대/축소, 긴 텍스트, 빈 상태 및 오버플로를 확인하십시오. 작은 화면에서 스크린샷에 맞추기 위해 숨기지 말고 의미 있는 콘텐츠와 동작을 유지하십시오.
보안 및 성능 유지
원격 콘텐츠와 URL을 신뢰할 수 없는 것으로 취급하십시오. 프레임워크 안전 렌더링을 사용하십시오. 풍부한 HTML이 필요한 경우 검증된 메커니즘을 통해서만 살균하십시오. 클라이언트 번들, 원격 측정 또는 오류 메시지에 비밀 또는 개인 기록을 노출하지 마십시오. 캐시된 데이터를 ID/테넌트로 범위를 지정하고 관련 컨텍스트 변경 시 지우거나 무효화하십시오.
불필요한 페치 워터폴, 값비싼 반복 작업, 과도하게 큰 의존성 및 레이아웃 이동을 피하십시오. 프레임워크의 에셋, 렌더링 및 로딩 규칙을 사용하십시오. 측정된 증거와 제품 예산을 기반으로 최적화하십시오. 메모이제이션, 가상화 또는 코드 분할을 기계적으로 추가하지 마십시오. 실험실 결과와 필드 성능은 서로 다른 증거이며 별도로 보고해야 합니다.
렌더링된 결과 확인
행동 범위를 위해 test-authoring을 사용하십시오. 관련 저장소 검사를 실행하고 현실적인 데이터로 사용 가능한 브라우저에서 애플리케이션을 검사하십시오. 영향을 받는 동작 및 상태 전환, 키보드 탐색, 포커스, 유효성 검사, 반응형 레이아웃 및 해당 브라우저 대상을 실행하십시오. 변경과 관련된 콘솔 및 네트워크 오류를 검사하십시오. 스크린샷은 외관을 보여주지만 상호작용의 정확성을 보여주지는 않습니다. 자동화된 접근성 검사는 적합성을 확립하지 않습니다.
렌더링된 출력을 승인된 디자인 또는 프로젝트의 기존 화면과 비교하십시오. 발견된 클리핑, 간격, 대비 또는 상호작용 문제를 수정하고 영향을 받는 상태를 다시 확인하십시오. UI를 확인하기 위해 파괴적인 라이브 작업을 실행하지 마십시오. 안전한 픽스처 또는 승인된 테스트 환경을 사용하십시오. 브라우저 액세스가 불가능한 경우, 인터페이스가 시각적으로 검증되었다고 말하지 말고 확인되지 않은 상태가 무엇인지 정확히 명시하십시오.
실제 변경 사항, 테스트된 흐름/뷰포트 및 중요한 한계를 보고하십시오. 독립적인 검토가 필요하고 가능하며 승인된 경우 code-review를 사용하십시오. 커밋, 푸시 및 게시는 승인된 git-delivery를 사용하십시오.