Skip to content

Latest commit

 

History

History
115 lines (80 loc) · 5.68 KB

project.md

File metadata and controls

115 lines (80 loc) · 5.68 KB
Raw

Assignment - Admin Backoffice

  • 해당 과제는 총 3개의 Step으로 구성되어 있습니다.
  • 모든 과제는 해당 레포에서 관리되어야 하며, 반드시 각 Step이 종료될 때 마다 PR 요청을 날려야 합니다.
    • 물론, 다른 사람들의 PR에 대한 리뷰도 가능합니다.
  • 서버는 필요할 때 편하게 말씀해 주세요.
  • 궁금증이 있으면 주저하지 말고 서로 커뮤니케이션하고, 그럼에도 해결되지 않는다면 질문을 남겨주세요.
  • 각 PR 마다 설계 의도를 작성해주세요. 좀 더 효율적인 리뷰가 가능할 겁니다.

프로젝트 설명

백오피스 기능 만들기

  • 대용량 데이터/w backend 서버의 백오피스 기능을 개발해 봅시다.
  • 진짜 백오피스를 만든다고 생각하진 말고, 기존의 데이터를 활용하여 인증/인가 없는 순수 로직을 개발한다고 생각해 주세요.
  • 새로 생성하는 테이블은 {테이블 이름}_{본인의 식별자} 로 반드시 구성해야 합니다.

Branch Guide

  • 해당 레포에 본인의 대표 브랜치를 생성합니다.
  • 이후, 각 Step 마다 해당 브랜치를 베이스로 하는 새로운 브랜치를 생성합니다.
    • 이 경우, 각 브랜치의 이름은 feature/{대표 브랜치 이름}_step0 과 같은 방식으로 생성합니다.
    • PR은 대표 브랜치 <- Step 브랜치로 진행합니다.
  • 필수적으로 PR Approve를 받아야 합니다. PR을 올리신 이후엔 리뷰어 지정 부탁드립니다. (@VSFe)
    • 가능하다면, 참여하시는 모든 멤버를 리뷰어로 지정해주세요. 서로의 코드를 읽고, 코멘트 하는 것도 많은 도움이 됩니다.

Git Convention

포맷

type: subject

body

type

  • 하나의 커밋에 여러 타입이 존재하는 경우 상위 우선순위의 타입을 사용한다.
  • fix: 버스 픽스
  • feat: 새로운 기능 추가
  • refactor: 리팩토링 (버그픽스나 기능추가없는 코드변화)
  • docs: 문서만 변경
  • style: 코드의 의미가 변경 안 되는 경우 (띄어쓰기, 포맷팅, 줄바꿈 등)
  • test: 테스트코드 추가/수정
  • chore: 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X)

subject

  • 제목은 50글자를 넘지 않도록 한다.
  • 개조식 구문 사용
    • 중요하고 핵심적인 요소만 간추려서 (항목별로 나열하듯이) 표현
  • 마지막에 특수문자를 넣지 않는다. (마침표, 느낌표, 물음표 등)

body (optional)

  • 각 라인별로 balled list로 표시한다.
    • 예시) - AA
  • 가능하면 한줄당 72자를 넘지 않도록 한다.
  • 본문의 양에 구애받지 않고 최대한 상세히 작성
  • “어떻게” 보다는 “무엇을" “왜” 변경했는지 설명한다.

Additional Requirement

각 PR의 요구사항과 더불어, 해당 명세를 반드시 만족해야 합니다.

  • Code Smell을 최소화 하세요.
    • SonarQube를 사용합니다. PR 과정에서 SonarQube Major Issue 발견 시, PR이 제한됩니다.
  • Code Convention 을 사용하여 코드를 작성해 주세요.
  • 여기서는 네이버 핵 데이 컨벤션을 사용합니다.
  • 가능하면, 다른 분들의 PR도 코멘트를 달아보도록 노력해보세요. 상대방의 코드를 지적하는 것만이 코드 리뷰가 아닙니다. 코드를 보고 배울 점이 있다고 생각해도, 가감없이 코멘트를 달아주세요.

Step 1. 이메일 발송 기능

구현사항

  • 일반적으로, 계좌를 생성하게 되면 계좌 상품의 설명서가 메일로 발송됩니다.
  • 저희는 해당 기능을 구현하기 전, 수동으로 메일을 전송하려고 합니다.
  • 다만, 매번 일일히 메일을 보내게 되면 리소스의 낭비가 발생할 수 있으므로, 분단위로 메일을 자동 전송 하려고 합니다.
  • 메일 전송 요청을 받아 메일 전송 요청을 남기고, 전송 후 결과를 남기는 테이블과 API를 생성해 주세요.

프로그래밍 요구사항

  • 분단위 메일 전송을 위해 CronJob 을 사용해야 합니다. 어떤 방식으로 생성이 가능한지 확인해 주세요.
  • 테이블에 들어가야 할 정보가 무엇이 있을까요? 잘 생각해 보세요.

Step 2. 송금 이력 통계화

구현사항

  • 새로운 통계 테이블을 생성합니다.
  • 일 단위 당일 전체 송금 금액, 해당 날짜 까지의 누적 송금 금액 을 담도록 작성해 주세요.
  • 해당 테이블을 조회하는 API (시작 날짜와 종료 날짜를 받는) 도 개발이 필요합니다.
  • 일반적인 경우 새벽 4시 에 전날 통계 집계가 진행되며, 필요 시 API를 통해 특정 날짜의 통계를 강제로 집계할 수 있어야 합니다.

프로그래밍 요구사항

  • 어려워보이나요? 대용량 데이터/w backend 2회차 세미나를 수강하시면 아주 큰 도움이 될 겁니다!
  • 배운걸 응용한다고 생각해 보세요.

Step 3. 사용자 전체 정보 조회

구현사항

  • 특정 사용자의 전체 정보를 조회 하는 API를 개발합니다.
  • 해당 사용자가 개설한 모든 계좌의 정보와, 모든 거래 내역을 조회할 수 있어야 합니다.
  • 해당 API를 두 가지 방법으로 개발하고, 각각에 대해 성능 테스트를 수행해 주세요.

프로그래밍 요구사항

  • 이 또한 위 세미나에서 언급한 내용을 활용하는 문제입니다.
  • 난이도는 Step 2 보다 낮지만, 실제 시나리오를 설계하여 성능테스트를 진행한 과정도 작성해 주세요.