Front-end development

업무 주요 순서

  1. 요구조건/정책(기획서) review
    • 전체를 한 번에 다 이해하는 것은 한계가 있기 마련이어서 구현할 때 필요한(맡은) 것만 찾아보면 된다는 입장이 있을 수 있지만, 그럼에도 흐름 중심으로 이해하는 관점은 여전히 중요합니다.
  2. R&R 및 Design system 협의
    • 화면 혹은 tab 기준으로, 개발 소요 시간을 예측합니다.
    • 화면 단위를 기준으로, 실무 개발자들이 자신이 맡을 부분을 선택하거나 할당 받습니다.
    • Design팀과 함께 Component 개발 범위를 협의합니다. (참조)
  3. 단위 기능 구현 및 review
    • 페이지 단위로 기획서를 톺아보면서 단위 기능을 구현합니다.
  4. Design system 적용 및 components 검증
    • Component module을 만들고 code를 review 합니다. (참조)
    • 만들어진 모듈을 App에 붙입니다. (위 2번 참조)
  5. Real data 연동
    • Persistent layer 데이터(REST, BFF, WebSocket 등)를 UI에 붙이고, 검증합니다.
  6. 통합 검증 대응
    • QA 품질 보증 업무에 대한 적극적인 대응이 필요합니다.
    • Error report template은 커뮤니케이션 비용을 최소화할 수 있도록, 객관적 근거를 명확히 하는 방향으로 사전에 팀간 합의를 통해 도출합니다.
    • Reports는 UI에서부터 드러나는 것이 대부분인 관계로, 원인이 모호한 것도 FE에서 우선 파악하여 FE와 관련 없는 것들을 관련팀으로 forwarding 합니다.
  7. Production hotfix 대응
    • Product의 심각한 오류의 경우, develop 공동 형상과 분리하여 빠르게 대응합니다.

검증 수준

(괄호 수치는 코드량에 비례하는 추가 필요 시간)

  1. TDD (2.0 ~ 3.0)
    • Code coverage: 자연스럽게 95% 이상 고수준 확보
  2. Component unit (1.5 ~ 2.5)
    • Code coverage: 조직마다 다르지만, 일반적으로 50~80% 내에서 결정
  3. E2E (1.2 ~ 2.0)

교육

Front-end web developer - Web 개발 학습하기 | MDN
프론트 개발자가 되는 과정에 오신 것을 환영합니다!
Git workflows
Git Workflow | Atlassian Git TutorialA brief introduction to common Git workflows including the Centralized Workflow, Feature Branch Workflow, Gitflow Workflow, and Forking Workflow.AtlassianAtlassianA successful Git branching modelIn this post I present a Git branching strategy for developing and r…
Learn web development
Explore our growing collection of courses on key web design and development subjects. An industry expert has written each course, helped by members of the Chrome team. Follow the modules sequentially, or dip into the topics you most want to learn about.
React TypeScript Cheatsheets | React TypeScript Cheatsheets
React TypeScript Cheatsheets