개인과제가 종료되기 무섭게, 팀 프로젝트가 발표되었다.

 

 

과제 기한은 09.13 ~ 9.25일 이다.

꽤나 길어 보이는 기간에 함정이 있었으니..

 

발제 당일과 제출하는 날과 휴일을 제외하면 19, 20, 23, 24   4일의 기간이다 !

 

크흠........

 

 

오늘의 목표

 

 

와이어 프레임

해당 팀 프로젝트는,  저번 개인과제와 마찬가지로 백엔드 중심의 구현에 초점이 있기 때문에,

프론트 부분은 구현을 안해도된다.

추후, 구현하게 되더라고 최대한 간단하게, insomnia 인터페이스와 유샤한 느낌으로 구성했다.

 

 

API 명세서

팀원과 상의하며, 작성한 API 명세서.

현재 1차적인 역할 분담까지 완료된 상태이다.

작업 진행속도나 상황에 따라 유연하게 바뀔 예정 !

 

 

ERD 

 

최초 계획에서 이미 피드백을 받고 수정이 이루어진 상태다.

 

불필요하다고 판단되는 Accounts_info 가 Accounts 에 병합되었고, 

 

그 외 players (선수) 의 내용을 참조가 아닌 복사해와서 쓰는  Roster (인벤토리 선수목록) 같은 형태는 

있어선 안된다는 피드백 (보안 문제, 유지보수가 불가능 수준이기에 현업에선 있을 수 없는 형태) 

을 통해 players 가 선수의 내용을 담고, 후에 강화정보는 Roster 를 통해 참조되기로 했다.

 

 

관련 지식이 없어서  전혀 모르고 있었지만, 튜터님께 들을 내용은 충격적이었다.

기존에 예상했던 방식 ->

아이템DB -> 해당 DB에서 아이템을 복사해서 인벤토리로 가져옴 -> 그 후 자유롭게 +- 제련 강화 기타 등등 작업하며 사용

 

이런 형태로 아이템의 흐름을 예상 했는데, 완전히 틀린 내용이었다.

 

이유로는, 

 

첫 번째 !!

만약 아이템이 상당량 풀린 상태에서 아이템의 수정 (패치로 조정) 이 이뤄져야 한다면, 

베이스db에서 수치를 조정하는건 당연하고, 

풀려있는 모든 아이템을 추적해서 직접 조정해야한다. 

이와 비슷한 내용의 유지보수가 현실적으로 불가능해 진다.

 

두 번째 !!

위와 비스무리한 이유로, 아이템이 어떤 과정을 통해 이런 결과로 변조되었는지 알 수 없게된다.

이는, 해당 아이템 데이터가 조작되어도 딱히 검증할 방법이 없는것이라 할 수 있다.

같은 이유로, 아이템의 강화 내용을 되돌리는 기능 같은것도 있을 수 없게된다..

 

따라서 ! 위의 ERD 표 처럼,  plalyers 의 값을 참조 하되, 추후에 강화기능을 만들게 된다면

roster 테이블에서 강화와 관련된 데이터를 관리하게 될 것이다.

 

계획은 이 정도 선에서 마무리 되었고 ,

 

내가 맏게된 파트는 팀 편성 관련 API 등등 이다. 

 

 

일정 상, 추석과 주말에 과제를 진행해야 겠지만,

 

이번 팀원들과 호흡이 잘 맞을것 같아 벌써부터 기대가된다 !!!!

 

 

+ Recent posts