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)
   • 정규 개발팀보다, QA팀 독립적으로 혹은 진취적인 기획팀이 주도적으로 실행
   • 참고 링크: https://fe-developers.kakaoent.com/2022/221222-cypress-studio-test-automation-low-code/

교육

• ES6(ECMAScript  2015) 기초 학습: https://www.zerocho.com/category/ECMAScript/post/5756d488e9c105aaeb550ea5