[SR] SR feedback

### ISSUE
- Group: sr
- Type: update
- Detail: SR 피드백

### — 기획 —

유저가 올리는 게임 패치정보들 -> 커뮤니티
크롤러 보다는 게시판 CRUD에 집중
유저끼리 자정작용 되는 게시판 사이트

게시글이 맞는지도 유저가 평가
인벤처럼 유저들이 게시물을 올리고 평가를 하고 (좋아요, 싫어요)


패치내역에 대한 맞아요, 틀려요(검증) 버튼, 선호도 측정
맞았을 때 보상, 그렇지 않을 때는

불특정 다수의 게임들의 패치내역을 통합관리
사용자들이 자정 작용을 하여 이끌어 갈 수 있는 서비스

댓글 및 버튼 같은걸 이용한 자정작용
평가가 낮으면 내려가게 (삭제)

카카오 로그인 API 를 이용한 -> OAuth
닉네임만 추가로 정하게

쪽지함 버리기

메인페이지에는 게임들의 목록 -> 목록을 클릭하면 패치게시물 -> 패치목록을 클릭하면 댓글들

자정작용을 어떻게 해야할까?
악의적으로 맞아요 틀려요를 조작한다면?

#### 보상 생각
- 레벨시스템, 경험치, 레벨에 대한 랭킹(서버에서)
- 나중에는 게임회사와의 제휴를 통해서 보상을 유저에게 준다(서비스확장성)

### — 스택 —

정정 Hibernate -> JPA
삭제 JSoup

#### FrontEnd

> - Next.js 도전
> - CSS로 모달 도전
> - 횡스크롤 도전




#### BackEnd

> - Graph.QL 적용 도전




### — API —

/user/login -> /login

겹칠때만 user 넣는걸로
굳이 login 없이

/oauth/login -> /oauth

load all game list
Subscribe games list 통합 / 파라미터로 처리

1. Post - 메시지 ok 만 하고
Response 에 정보 ㄴㄴ
Get - info 에서 받아오는걸로

2. Modify 를 Post 에서 Put 으로 변경 -> Update

### — Requirements —

- BareMinimum
- 선호 게시판 선택 기능
- 맞아요 틀려요버튼
- Advanced
- 알림기능(issue)

### — 기타 —

경우의수를 끝까지 생각해보세요
팀내 커뮤니케이션 중요

메소드 하나마다 올리기 PR
- 다른사람의 개발이 딜레이되는걸 방지하자

#### 우리가 알아야 하는 문서 3가지
우리가 쓴 것은 제안서사이와 기획서 사이의 어떤 것

1. 제안서
- 회사 내에서 아이디어가 있어서 올리는 문서(내부문서, 내부제안서)
- 내가 만드려는 서비스의 핵심 기능, 차별점을 명시해 놓은 문서

2. 기획서
- 제안서를 구체화 시켜 놓은 문서

3. 사양서
- 문서만 봐도 코드가 나올 수 있고, 개발자가 바뀌어도 동일한 코드가 나올수 있도록 한다. 모든 기능들에 대한 아주 사소한 단위까지 구체적으로 만들어 놓은 문서




### — Lint —

사소한 부분까지 문서화 해라
네이밍규칙은 누구나 쉽게 이해할 수 있도록, 라이브러리와 겹치지 않게

#### BackEnd

Private 카멜
Public 파스칼
Function 네이밍 규칙등

#### FrontEnd

ESLint 따라서
규칙 문서화