👨‍👩‍👦팀원 소개 (R&R)

정준현

• PM(Project Manager)
  • 프론트엔드와 백엔드를 포함하는 프로젝트 전체를 리드
  • 프로젝트에 대한 모든 책임
• 백엔드 개발자
  • 백엔드 파트 구현
  • 백엔드 코드 취합
  • 서버 관리
• README

김재유

• 프론트엔드 PL(Proejct Leader)

  • 프론트엔드 파트 를 리드하고 백엔드와의 협업을 위한 소통을 담당
  • 프론트엔드 파트의 업무 조율

• 프론트 개발자

  • 프론트엔드 파트 구현
  • UI/UX 고안 후 구현

• README

길아현

• CTO (Chief Technology Officer)
  • API, 외부 라이브러리 도입 등을 결정
  • 새롭게 도입된 정보와 지식을 다른 팀원들에게 전파
• 프론트 개발자
  • 프론트엔드 파트 구현
  • UI/UX 고안 후 구현
• README

염성훈

• 마스코트
  • YUM? YUM! 쿼카 이미지 모티브 제공
• 프론트 개발자
  • 프론트엔드 파트 구현
  • 외부 API(카카오지도)
  • UI/UX 고안 후 구현
• README

이수민

• 백엔드 PL(Proejct Leader)

  • 백엔드 파트를 리드하고 프론트엔드와의 협업을 위한 소통을 담당
  • 백엔드 파트의 업무 조율

• 백엔드 개발자

  • 백엔드 파트 구현
  • DB 스키마 설계

• README

✨ 프로젝트 개요

Sub-PJT 1 (21.01.11 ~ 21.01.15 <총 1주>)

• 목표 : 차주 팀프로젝트 준비(기획, 프로젝트 규칙 등)

  자세히

  - 팀 프로젝트를 위한 도구 연습. Gitlab, Jira 등
  - 개인프로젝트이지만 팀으로 대응!! (이슈 발생 시 팀원 공유)
  - 팀프로젝트 개발 환경 구축
  - React에 대한 전반적인 학습(개요 수준!)

---

Sub-PJT 2 (21.01.18 ~ 21.01.29 <총 2주>)

• 목표 : 본격적인 프론트엔드, 백엔드 개발을 진행

  자세히

  - 같은 파트 내의 사람들과 원활한 협업과 소통
  - 각 파트별로 사용하는 프레임워크에 대한 숙련도 상승
  - 프론트엔드와 백엔드 간 REST API 통신에 대한 이해
  - 구현 서비스와 맞는 와이어프레임, 목업, DB 스키마 정의

Sub-PJT 3 (21.02.01 ~ 21.02.19 <총 3주>)

• 목표 : 백엔드, 프론트엔드 배포 주요기능 완성

  자세히

  - 메인영상피드, 지도, 유레카 기능 완성
  - 스마트폰 해상도에 맞게 CSS 반응형으로 구현
  - 실제데이터로 기능이 정확이 동작하는지 확인
  - UCC제작 및 README.md 작성

🧑‍🤝‍🧑협업규칙

상시 약속

• 1일 1커밋, 1주 1MR(Merge Request) 1인 프로젝트라도 master 브랜치에서 작업하지 말자(연습)
• Jira 이슈 관리
  • 스토리 포인트도 적극적으로 활용
• 공부한 내용이나 막힌 이슈를 README.md로 정리!!!
• 상대방에게 영향을 끼칠 코드 변경 사항이 있을 경우 바로 바로 보고
  • 새로운 기능 구현
  • URL
  • 주고 받는 데이터 형식
  • 상대방이 구현하기로 정한 파일에서 코드 변경이 필요할 경우

하루를 시작하며

1. 지라를 통해 어제 한 일, 오늘 할 일 반영.
2. 어제 한 일 중에 상대방에게 영향을 끼칠 코드 변경 사항이 있을 경우 보고
   • URL
   • 주고 받는 데이터 형식
3. 데일리 스크럼 진행
4. 필요하다면 같은 기술 스택 사람끼리 코드 리뷰 진행

하루를 마무리하며

1. 지라에 오늘 한 일 반영
2. 오늘 한 일 중에 사람들에게 보고할 만한 내용 정리
3. 1일 1커밋 수행 (커밋 메시지 컨벤션 지킬 것)

프론트 엔드 코딩 컨벤션 [접기/펼치기]

👩‍💻프론트 엔드 코딩 컨벤션

1. File 구조

• 컴포넌트는 함수형 으로 구성합니다.

• 하나의 파일에는 하나의 React 컴포넌트를 사용합니다.

• 그러나, 다중 스테이트가 없는(Stateless) 또는 순수한 함수나 컴포넌트는 허용됩니다.

• 스타일링은 Prettier-Code formatter 플러그인을 통해 통일합니다.

// 구성요소는 더 찾아보고 합의해봅시당

{
  "useTabs": false,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "all",
  "semi": true,
  "singleQuote": true
}

2. 폴더 구조

• 기능과 역할에 따라서 폴더를 구성합니다.
• 화면 구성요소가 아닌 기능요소는 폴더명 앞에 언더바(_)을 붙여서 구분합니다.

3. 변수

• 변수는 가능하면 불변변수는 const사용합니다.

4. Naming

• 파일명은 PascalCase를 사용합니다. ex) LoginPage.jsx

• 파일이름과 컴포넌트이름은 통일합니다.

• 구성요소의 확장자는 .jsx를 사용합니다.

5. 프로퍼티

• prop의 이름은 항상 camelCase를 사용합니다.

• props는 읽기전용을 기본으로 한다. 수정되면 안된다. (수정이 필요한 정보는 state!)

• React 컴포넌트는 props를 다룰 때 반드시 순수함수처럼 사용해야한다.

  • 순수함수?

  기본적으로 입력 데이터를 변경하지 않고 외부 상태 (데이터베이스, DOM 또는 전역 변수와 같은)에 의존하지 않으며 동일한 입력값에 대해 동일한 출력값을 일관되게 제공하는 함수를 “순수(pure)” 함수라고 한다.

• 프로퍼티(props)로 값을 전달할 때에는 문자열은 큰따옴표("") , 이외의 값은 중괄호({})를 사용합니다.

// 예시

class App extends React.Component {
  render() {
     // 전달할 때 지저분한 요소들은 변수에 할당 후 넘겨줍니당
    const array = [1,2,3];
    const obj = {name: "YUM", age:"3000"}
    const node = <h1>안녕하세요</h1>;
    const func = () => {console.log('안녕하세요'); };
    return (
      <ChildComponent
        stringValue="string"
        boolValue //boolean의 경우 보내면 true 안보내면 false가 알아서 할당됩니당.
        numValue={1}
        arrayValue={array}
        objValue={obj}
        nodeValue={node}
        funcValue={func}
        />
    );
  }
}
export default App;

• 프로퍼티를 받아온 경우, 자료형을 하단에 선언해 줍니다.

// 해당 내용이 함수형에도 적용되는지 몰겠!

import PropTypes from 'prop-types'

...

PropsComponent.propTypes = {
    stringValue: PropTypes.string,
    boolValue: PropTypes.bool,
    numValue: PropTypes.number,
    arrayValue: PropTypes.arrayOf(PropTypes.number),
    objValue: PropTypes.shape({
        name: PropTypes.string,
        age: PropTypes.number,
    }),
    nodeValue: PropTypes.node,
    funcValue: PropTypes.func,
} 

6. 태그

• 자식을 가지지 않으면, 항상 자신을 닫는(self-close) 태그를 사용합니다.
• self-closing에는 한칸의 공백만 사용합니다.

// DO NOT
<sample className="sample"></sample>

// DO
// self-closing에는 한칸의 공백만 사용합니다.
<sample className="sample" />

• 멀티라인의 경우, 여는 태그와 닫는 태그를 다른 줄에 위치한다.

// DO NOT
<sample className="sample"
    type="YUM" />

// DO
<sample 
  className="sample"
  type="YUM" 
/>

7. Redux

• 액션

  • Type은 어떤 작업을 위한 것인지 명확하게 명명합니다.
  • Type은 대문자와 언더바로 구성합니다.

• 리듀서

  • 리듀서가 반환하는 값의 자료형은 이전 데이터와 동일해야 합니다.

    (콩심은데 콩나고 팥심은 데 팥난다)

8. 인라인 표현

• If문

  • 중괄호 내에 논리연산자 &&을 사용해 표현합니다.

  // 예시
  
  <div>
      <h1>Hello!</h1>
      {unreadMessages.length > 0 &&
          <h2>You have {unreadMessages.length} unread messages.</h2>
      }
  </div>

• If-else문

  • condition ? true: false형태를 사용해 표현합니다.

  render() {
    const isLoggedIn = this.state.isLoggedIn;
    return (
      <div>
        The user is <b>{isLoggedIn ? 'currently' : 'not'}</b> logged in.
      </div>
    );
  }

9. 프로젝트 설계의 흐름

• 동일하진 않더라도, 프로젝트의 흐름은 다음과 같습니다. 이 페이지를 참고해 구성했습니다.
  1. 페이지의 전체 구조를 생각하고, UI를 컴포넌트 계층 구조로 나누기
  2. UI는 있지만 기능은 없는 정적인 버전 만들기
  3. 최소한의 state 파악 및 설계
  4. 역방향 데이터 이동 설계

10. 디자인

• 디자인 라이브러리를 사용할 경우, Material-UI 로 통일한다.

백엔드 코딩 컨벤션 [접기/펼치기]

👨‍💻백엔드 코딩 컨벤션

깃 커밋 메시지 컨벤션과 마찬가지로 자바 명명 규칙도 처음 보는 사람들이 읽기 쉽게끔 모두가 공유하기 쉬운 컨벤션을 가지고 이름을 지어야 한다.

1. Naming (명명 규칙)

1. 기본적으로 네이밍은 누구나 알 수 있는 쉬운 단어를 선택한다.

   • 우리는 외국인이 아니다. 쓸데없이 어려운 고급 어휘를 피한다.

2. 변수는 CamelCase를 기본으로 한다.

   • private String secondName = "William"

3. URL, 파일명 등은 kebab-case를 사용한다.

   • /user-email-page ...

4. 패키지명은 단어가 달라지더라도 무조건 소문자를 사용한다.

   • frontend, useremail ...

5. ENUM이나 상수는 대문자로 네이밍한다.

   • public String NAME = "June" ...

6. 함수명은 소문자로 시작하고 동사로 네이밍한다.

   • getUserId(), isNormal() ...

7. 클래스명은 명사로 작성하고 UpperCamelCase를 사용한다.

   • UserEmail, Address ...

8. 객체 이름을 함수 이름에 중복해서 넣지 않는다. (= 상위 이름을 하위 이름에 중복시키지 않는다.)

   • line.getLength() (O) / line.getLineLength() (X)

9. 컬렉션은 복수형을 사용하거나 컬렉션을 명시해준다.

   • List ids, Map<User, Int> userToIdMap ...

10. 이중적인 의미를 가지는 단어는 지양한다.

    • event, design ...

11. 의도가 드러난다면 되도록 짧은 이름을 선택한다.

    • retreiveUser() (X) / getUser() (O)
    • 단, 축약형을 선택하는 경우는 개발자의 의도가 명백히 전달되는 경우이다. 명백히 전달이 안된다면 축약형보다 서술형이 더 좋다.

12. 함수의 부수효과를 설명한다.

    • 함수는 한가지 동작만 수행하는 것이 좋지만, 때에 따라 부수 효과를 일으킬 수도 있다.

      fun getOrder() {
        if (order == null) {
            order = Order()
        }
      return order
      }
      

    • 위 함수는 단순히 order만 가져오는 것이 아니라, 없으면 생성해서 리턴한다.

    • 그러므로 getOrder() (X) / getOrCreateOrder() (O)

13. LocalDateTime -> xxxAt, LocalDate -> xxxDt로 네이밍

14. 객체를 조회하는 함수는 JPA Repository에서 findXxx 형식의 네이밍 쿼리메소드를 사용하므로 개발자가 작성하는 Service단에서는 되도록이면 getXxx를 사용하자.

2. Structure

구조 설계에 대한 고민은 항상하기 마련이다. 좋은 설계를 위해 꾸준히 고민하고 리팩토링 작업하는 것을 지향한다.

1. 패키지는 목적별로 묶는다.
   • user(User 관련 패키지), coupon(쿠폰 관련 패키지)
2. Controller에서는 최대한 어떤 Service를 호출할지 결정하는 역할과 Exception처리만을 담당하자.
   • Controller 단에서 로직을 구현하는 것을 지양한다.
   • Controller의 코드 라인 수를 줄이자는 뜻은 절대 아니다.
3. 하나의 메소드와 클래스는 하나의 목적만 수행하게 만든다.
   • 하나의 메소드 안에서는 한 가지 일만 해야한다.
   • 하나의 클래스 안에서는 같은 목적을 둔 코드들의 집합이여야한다.
4. 메소드와 클래스는 최대한 작게 만든다.
   • 메소드와 클래스가 커진다면 하나의 클래스나 메소드 안에서 여러 동작을 하고 있을 확률이 크다.
   • 수많은 책임을 떠안은 클래스를 피한다. 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더욱 바람직하다.
   • 클래스 나누는 것을 두려워하지 말자.
5. 도메인 서비스를 만들어지는 것을 피하자.
   • User라는 도메인이 있을 때, UserService로 만드는 것을 피한다.
   • 이렇게 도메인 네이밍을 딴 서비스가 만들어지면 자연스레 수많은 책임을 떠안은 큰 클래스로 발전될 가능성이 높다.
   • 기능 별로 세분화해서 만들어보자. (UserRegisterService, UserEmailService 등...)

3. Programming

1. 반복되는 코드를 작성하지 않는다.

   • 단, 테스트코드는 예외로 한다.

2. 변수는 최대한 사용하는 위치에 가깝게 사용한다.

3. 파라미터 변수와 내부 변수를 구별할 땐 언더바가 아닌 this로 구별한다.

   • this.name = name (O) / name = _name (X)
   • 추가적으로 언더바를 prefix로 사용하는 것을 지양하자.

4. 코드의 길이가 짧고 명료한 것도 좋지만, 가독성이 현저히 떨어진다면 코드를 좀 더 풀어쓴다.

   • 무조건적으로 코드가 짧은 것이 좋다고 생각하지 않는다. 다른 개발자가 본다면 가독성이 현저히 떨어진다.
   • 특히나 최신 언어(kotlin 등)의 경우 코드의 길이를 현저히 줄일 수도 있지만, 제3자의 입장에서 봐도 어느정도 가독성이 있는지 다시 한번 확인하는 작업을 하자.

5. 모든 예외는 무시하지말고 처리한다. 만약 예외를 처리하지 않을거라면 그 이유에 대해서 명확하게 주석을 남긴다.

6. 예외를 던질 때는 최대한 세부적인 Exception(= Custom Exception)을 던진다.

   • 실패한 코드의 의도를 파악하려면 호출 스택트레이스만으로 부족하다.
   • 오류 메세지에 전후 상황의 정보를 담아 예외와 함께 던진다.

7. 예외 케이스가 발생할 확률이 있는 경우, 가능한 빨리 리턴 또는 예외를 던지도록 작성한다.

   • 쓸데없이 정상로직을 태울 필요가 없게한다.

     if(!정상) {
       throw err;
     }
     정상 로직
     }
     

8. 조건이 복잡한 경우 임시 boolean 변수를 만들어 단순화한다.

9. 조건문에 부정조건을 넣는 것을 피한다.

   • if(status.isNormal()) (O) / if(!status.isAbnormal()) (X)

10. 최대한 객체 타입 대신 기본 자료형을 선택하고, 생각지도 못한 Autoboxing이 발생하지 않도록 유의한다.

커밋 메시지 컨벤션 [접기/펼치기]

👨‍💻커밋 메시지 컨벤션

Why ❓

사실 지금껏 혼자서 프로젝트를 진행해오는 일이 많아서 깃 커밋 메시지를 나만 알아보면 되므로 중구난방으로 적는 일이 많았다.

그러던 중 최근에 팀 프로젝트를 진행하면서 남이 알아보기 쉽게끔 신경써서 커밋 메시지를 작성해야할 일이 생겼다.

그런데 팀 플젝이 아니더라도 몇 개월 뒤에 내가 쓴 커밋 메시지를 보게 되면 이 당시의 내가 무슨 생각으로 커밋 메시지를 작성했는지 알 수가 없다....(나를 위해서 라도 커밋 메시지를 신경써서 적도록 하자.)

정리하자면, 크게 3가지 이유로 좋은 커밋 메시지를 작성해야 할 것이다.

1. 더 좋은 커밋 로그 가독성
2. 더 나은 협업과 리뷰 프로세스
3. 더 쉬운 코드 유지 보수

커밋 메시지 구조 (Commit Message Structure)

커밋 메시지 구조는 제목(subject) / 본문(body) / 꼬리말(footer)로 구성된다.

본문과 꼬리말은 반드시 포함될 필요는 없다.

type : subject (이 곳은 제목이 들어갈 자리입니다.)

body (이 곳은 본문 내용이 들어갈 자리입니다.)

footer (이 곳은 꼬리말이 들어갈 자리입니다.)

커밋 타입 (Commit Type)

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor : 코드 리팩토링
• test : 테스트 코드, 리팩토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정

제목 (Subject)

• 커밋 메시지 제목은 제일 앞에 제목의 타입을 붙여준다. 커밋 타입의 종류는 위 내용을 참고한다.
• 제목은 50자를 넘기지 않고, 대문자로 작성하고 마침표를 붙이지 않는다.
• 과거 시제를 사용하지 않고 명령어로 작성한다.
• 커밋 유형들이 복합적인 경우에는 최대한 분리하여 커밋한다.

본문 (Body)

• 선택 사항이므로 작성하지 않아도 무방하다.
• 부연설명이 필요하거나 커밋의 이유를 전달해야할 경우 작성한다.
• 내용은 어떻게 변경하였는지 보다 무엇을, 왜 변경하였는지를 설명하는 위주로 작성한다.
• 한 줄이 72자를 넘기지 안고 제목과 구분되게 한 줄을 띄우고 작성한다.

푸터 (Footer)

• 선택 사항이기 때문에 작성하지 않아도 무방하다
• 보통 이슈를 추적하기 위해 이슈 트래커 ID를 넣어주는 용도로 사용된다.

예시 (Example)

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

⚙️ Install and Usage

Frontend

• frontend 폴더로 들어와 필요한 패키지를 설치합니다.

  yarn

• frontend app을 실행합니다.

  yarn start

Backend

• Java (Open JDK 14)를 설치합니다.
• Maven을 설치합니다.
  • VSCode에서 Maven 하단의 webcuration에서 우클릭 후 install
• VS Code에서 Spring Boot Extension Pack 설치합니다.
• Docker를 설치합니다.

Maria DB 컨테이너 실행

• docker run --name-db -p 3306:3306 -e MYSQL_ROOT_PASSWORD={패스워드} -d mariddb
  • 패스워드를 칠 때는, 대괄호를 지우고 칩니다.
• docker exec -it maria-db mysql -u root -p
  • docker를 켜고, maria-db를 실행하기 위한 코드입니다.

DB 테이블 생성

• DB 테이블을 생성합니다.

backend 앱을 실행합니다.

• ./mvnw spring-boot:run

💡 아이디어 기획

1) 기획 목표

생생한 기억이 담긴 피드(Feed)

• 맛있는 음식을 먹었던 기억을 영상과 함께 생생하게 기록할 수 있습니다.

• 다른 사람들이 작성한 피드를 한눈에 볼 수 있고 서로 공유할 수 있습니다.

세상에 하나뿐인 맛집 지도

• 본인이 찜한 식당들만 모아 지도에서 확인하세요.
• 다른사람들이 다녀간 주변의 맛집들도 확인 할 수 있어요.

맛집 유레카를 외치세요!!!

• 맛집을 발견한 기쁨을 주변 사용자들에게 전파할 수 있어요.

2) 와이어 프레임 (Wireframe)

목업 툴을 활용하기 전에 저희가 생각한 기능들을 표현하기 위해 간단한 구조와 컨텐츠를 스케치!

3) 목업 (Mock-up)

4) DB 스키마

현재 기획된 서비스 내에서 필요한 스키마는 전부 구현되어있는 상황입니다.

프로젝트를 진행하면서 필요한 Column이 생기게 되면 새롭게 스키마를 수정해나가면서 맞춰나갈 계획입니다.

🏠 주요 기능

1) 회원 관리

유저 정보를 다루기 위한 기능들

1. 회원 가입
   • 이메일, 이름, 비밀번호로 가입 가능
   • 가입 필수 항목 모두 입력 시에만 가입되도록 변경
   • 이메일, 비밀번호 등 입력 기준이 충족되지 못할 시 오류 메시지 노출
2. 로그인
   • 이메일, 비밀번호 오류시 오류 메세지 노출
   • 로그인 실패 시 사용자에게 실패 사유 오류메시지 노출
   • JWT Token 활용 보안성 강화

2) 피드

맛있는 음식 영상과 함께 맛집 정보와 평가를 담은 게시글

1. 피드 작성 페이지

   • 휴대폰으로 찍은 영상을 화면에 보여주고 서버에 저장
   • 지도 API를 활용해서 정확한 가게 위치 정보를 입력
   • 음식점과 직접해먹은 음식을 분류하여 저장
   • 먹은 음식을 제목으로 지정하고 별점과 내용을 입력

2. 피드 플립 페이지

   • 피드 페이지의 배경으로 영상을 자동 반복 재생
   • 피드 CRUD 구현
   • 다른 유저가 작성한 피드를 접할 수 있는 페이지
   • 닉네임 클릭시 다른 유저의 마이페이지 접근 가능
   • 좋아요 항목을 지도에서 확인 가능
   • 인피니티 스크롤을 통해 영상이 끊기지 않도록 구성

3) 지도

피드로 저장된 장소를 지도에 마커의 형태로 활용 가능

1. 리뷰 지도

   • 좋아요 한 리뷰는 도토리로, 전체 리뷰는 기본마커로 지정하여 분류하여 표시
   • 좋아요 한 리뷰를 목록으로 확인할 수 있음.
   • 마커클릭시 음식점의 간단 정보를 바텀 시트에 표기
   • 바텀 시트에서 리뷰보기 클릭 시 해당 음식점에 작성된 모든 리뷰를 그리드로 표기
   • 썸네일을 누르고 있을시 음식 영상 자동 재생
   • 썸네일 클릭시 해당 디테일 리뷰 페이지로 이동
   • 지도 축소시 마커를 클러스터 갯수로 모아 표기

2. 검색 지도

   • 내 위치 거리 기반 가까운 음식점을 검색하여 지도위에 마커와 리스트로 표기
   • 리스트를 클릭하거나 마커를 클릭하면 해당 음식점의 장소 및 정보를 저장

4) 마이페이지

내가 작성한 리뷰를 최신순, 메뉴별로 확인

1. 유저 페이지

   • 작성한 리뷰를 그리드로 보기 편하게 구현
   • 썸네일을 누르고 있을시 음식 영상 자동 재생
   • 썸네일 클릭시 해당 디테일 리뷰 페이지로 이동

2. 유저 정보 변경

   • 계정 설정에서 입력된 데이터가 변경되지 않았을 경우 오류 메세지 노출

   • 닉네임, 한줄 소개, 유저 프로필 아바타 변경

   • 비밀번호 변경 기능

5) 유레카

새로운 맛집을 찾게 된 기쁨을 나누거나 나만 알고 있는 맛집을 주변에 공유하고 싶을 때 외치세요!

1. 맛있는 식당을 주변에 실시간으로 알려주는 기능
2. 유레카
   • 좋아요, 싫어요 받을 때마다 피드 게시 시간 증가, 감소
3. 위 기능들은 하루에 정해진 충전량을 소모시키면서 수행 가능
4. 4가지 메세지를 선택해서 다른 유저와 소통
5. 현재 위치를 기반으로 주변 1km의 유저와 소통 가능

👀 페이지 화면

FEED

음식 영상과 간단 리뷰내용으로 구성

메인 FEED and LIKE

리뷰 내용 펼치기

피드 생성

마이페이지

기본 페이지

유저정보변경

비밀번호 변경

지도

좋아요, 모든리뷰 구분

바텀시트

좋아요 리뷰 목록

클러스터

유레카

유레카 클릭 애니메이션

4가지 메세지 선택

시연영상

• https://youtu.be/xcw8BY_VGmU