평소 즐겨하던 피파온라인4 (현 FC ONLINE)라는 플랫폼에서 제공하고 있는 API를 통해 저만의 웹으로 추가적인 경험을 제공하기 위한 프로젝트 입니다
실제 축구 경기에서 제공하는 각 매치별 통계를 피파온라인4에서 유저들이 직접 플레이 했던 경기에 대해 제공 합니다.
자세한 수치를 기반으로 한 경기 분석 및 통계, SVG를 통한 좌표 시각화, 이적시장 활동 로그의 기록들을 볼 수 있으며 다양한 옵션도 적용 가능합니다.
상위 구간 플레이어들의 (top 10000) 실제 선수 기용 데이터를 통해 피파온라인에서 사용되고 있는 각 선수의 포지션 별 통계를 보여줌으로써, 해당 선수가 어떠한 포지션에서 사용할 때 가장 효율적인지에 대해 추천해주는 기능입니다
검색한 유저와의 1:1 매치 통산 전적을 보여줍니다.
전체적인 승률과 함께 해당 경기에 대한 자세한 통계 또한 볼 수 있습니다
- 프로젝트 로그인 페이지 입니다
- 구글 로그인 , 게스트모드 로그인이 존재합니다
- 이 서비스에서 사용할 계정을 입력하며, 유효성 검사를 통해 실제 존재하는 피파온라인4 계정만 입력이 가능합니다
- 로그인 후 진입하는 메인 메뉴 페이지 입니다
- 서비스의 소개 및 전체 메뉴가 있습니다
react-awesome-reveal을 사용하여 동적인 효과를 주었습니다
-
로그인 한 계정에 대한 정보들을 보여줍니다.
-
공식경기 최고기록
-
플레이 기록 (최대 경기 수 선택 가능)
- 리그 친선
- 친선 1대1
- 공식경기 (일반, 감독모드, 친선)
-
이적시장 로그 (최대 갯수 선택 가능)
- 판매기록 과 구입기록을 보여주며 , 아래의 필터링 옵션을 적용할 수 있습니다
- 가격 내림차순
- 가격 오름차순
- 오래된 순
- 최신 순
-
- 경기 기록 및 통계 제공
- 시간 별 득점 기록
- 점유율 , 코너킥 , 파울 , 옐로카드 등 전반적인 기록
- 슈팅 및 득점 X,Y 좌표를 SVG의 좌표에 맞게 직접 계산 후 적용
- 패스 , 수비 기록 차트
- 실제 선수가 가용된 포지션 데이터를 좌표를 받아옵니다. 이걸 기반으로 모든 포메이션에 호환이 되는 경우의 수를 고려해 SVG의 좌표로 계산해서 실제 플레이 했던 포메이션대로 보여줍니다
- 전 세계적으로 유명한 축구 평점 사이트 whoscored 의 실제 평점 시작화 이미지를 따라서 구현 했습니다
- 상대의 닉네임을 검색 후, 지금까지 맞붙었던 전체 기록과 승률을 볼 수 있습니다
- 각 매치를 클릭하면 세부 통계를 볼 수 있습니다
- top 10000 랭커들의 실제 플레이 데이터를 기반으로 각 선수들의 포지션 별 기록을 보여 줍니다
- 최대 4개까지 선택이 가능하며 선택한 데이터 중, 가능 높은 수치들을 표시합니다
input창의 자동완성 기능이 포함되어 있습니다- 끊김이 없는 UX를 위해 포지션 선택이 4개를 초과할 시 자동으로 첫번째 선택이 삭제되며 , 다른 시즌을 선택하면 선수 이름도 같이 초기화가 됩니다
✔️스스로 적용해보면서 구상해 본 저만의 컨벤션 입니다
🔹main
- 배포가 가능한 상태의 브랜치입니다. Vercel을 통한 CD가 적용됩니다.
🔹dev
- 최신 상태를 유지하는 브랜치 입니다. 이슈 단위 기능이 완료될 때마다 dev에 merge 후 , main에 PR을 날립니다.
🔹dev #이슈번호
-
각 이슈별 기능을 구현하는 브랜치 입니다. 해당 이슈 구현이 완료되면 dev에 merge하며 이 브랜치들은 삭제됩니다
브랜치 컨벤션 예시
-
이슈 37을 생성
-
로컬에 dev-#37 브랜치 생성하고 origin에 push해서 dev-#37 생성
-
dev-#37 에서 해당 이슈의 기능 개발
- 해당 기능 구현이 완료되면 dev-#37브랜치에서 커밋 ( 커밋메세지에 이슈번호 기입 ex) [#37][FEAT] OO기능 구현 )
- origin의 dev-#37에다가 push (origin의 dev-#37에 기능 구현 사항 반영)
-
로컬의 dev 브랜치로 넘어가서 dev-#37와 merge ( 동시에 충돌 확인 )
- 별 이상이 없다면 origin dev에도 push
-
최종적으로 dev에서 main으로 PR
브랜치 컨벤션 예외 사항 (이슈 분리)
-
이슈는 최소한의 단위로 작성하지만 , 만약 해당 이슈의 기능구현 도중 의도치 않게 수정 내용이 길어지거나 카테고리가 다양화 된다면 해당 이슈에서 각 진행사항들을 task로 분리한다
예를 들어 , 이슈 번호 6번이 있고 만약 여기서 파생된 이슈번호 7,8,9가 생겼을 때
-
각 파생된 이슈번호에 맞게 브랜치 dev-#7 dev-#8 dev-#9 를 새로 생성한다. 그리고 여기서 각 기능을 구현한다
브랜치 dev-#6는 실제로 존재하지 않게 된다. 왜냐하면 여기서 파생된 dev-#7 dev-#8 dev-#9에서 해당 기능들을 구현하기 때문
-
각 브랜치에서 기능구현이 완료되면 커밋하는데 커밋메세지도 각각 기존 방식처럼 이슈 번호를 기재한다
- dev-#7 에서 개발한 내용은 커밋 메세지가 [#7] 로 시작하고
- dev-#8 은 [#8]
- dev-#9 는 [#9] 로 작성하는 것이다
-
그리고 dev-#7 dev-#8 dev-#9 브랜치에서 각각 PR을 날리면서 해당 이슈번호에 대해서만 close한다 dev-#7 에 대해 PR날릴 땐 파생된 이슈번호 #7의 이슈만 close하는 것이다
기존 이슈인 #6은 close안 하고 냅둔다 dev-#7 에서 구현완료되면 #7에 대해서만 PR날리는 것이다
-
그리고 파생된 #7 #8 #9 이슈들이 최종적으로 다 완성되면 #6 이슈는 수동으로 close해준다
브랜치 컨벤션 예외 사항 (에러 발생)
만약 특정 이슈에 대한 개발이 완료되었을 때 , 커밋을 하고 PR을 날릴텐데 로컬에선 문제가 없었지만, 깃허브에서 의도치 않은 에러(ex 배포 에러)가 발생해서 수정을 해야 할 경우
깃허브의 PR은 close되기 전까지는 해당 브랜치의 변경사항이 실시간으로 자동반영되는 특성을 이용한다
예를 들어 #188 에 대해 개발을 하고 커밋했지만 배포단계에서 의도치 않은 에러가 발생했을 경우
- 해당 dev-#188 에 가서 다시 문제를 수정하고 커밋한다
- 이 역시 #188 이슈에 대한 구현 과정중 하나이므로 커밋메세지는 그대로 [#188]로 작성한다 그리고 dev-#188에 다시 push해준다
- 최종적으로 에러가 해결이 되면 그때 최종적으로 dev→main에 PR을 날려주는 것이다
즉, 최종 main으로 PR날리기 전에 해당 브랜치에서 추가 수정 및 커밋을 진행하다가 > 최종적으로 에러가 다 해결되면 마지막에 dev→main에 PR 날려서 merge하라는 것이다
✔️ 기능 구현
- [Feat] : 제목
1. 구현 기능(최대한 자세히)
2. 진행 사항
2. 진행 사항
3. 참고 사항
✔️ 리팩토링
- [Refactor] : 제목
1. 개선 사항 및 이유 (최대한 자세히)
2. 진행 상황
3. 참고 사항
✔️ 버그 픽스
- [BUG] : 제목
1. 문제점 (최대한 자세히)
2. 수정 사항 및 이론 (최대한 자세히)
3. 배운 점
✔️ DOCS 문서 작성
- [DOCS] : # 이슈번호 , 제목
1. 작성 사항
하나의 이슈에서 task로 분리됐을 경우 , 각 분리된 이슈들은 제목 앞에 (Tracked by #파생된 번호) 라는 접두어가 붙습니다
✔️ Gitmoji 사용
- FEAT : 새로운 기능을 추가할 경우
- FIX: 버그를 고친 경우
- DOCS: 문서 수정 (README.md 작성)
- DESIGN : CSS 등 사용자 UI 디자인 변경
- STYLE: 코드 포맷 변경( 오타 수정 , 탭 사이즈 변경 , 변수명 변경 등… )
- REFACTOR: 코드 리펙토링
- TEST: 테스트 코트, 테스트 코드 리팩토링
- CHORE: 빌드 업무 수정, 패키지 매니저 수정( package.json 수정 , .gitignore 수정 , 모듈 변경)
- (폴더 구조 변경에 대한 사항은 기록하지 않습니다)