[LUVOOK] 프로젝트 마지막

5taecoo·2022년 6월 23일
JavaScriptLUVOOKReactproject
0

Project

목록 보기
9/9
post-thumbnail

지금 당신에게 필요한 책, LUVOOK

최종 결과물

배포사이트 <- 구경하기

깃헙은 추후 공개 예정이다.



Git Branch 구성

🛠 브랜치 구성 및 관리

브랜치 구성

  • main
    • 배포용 메인 브랜치
  • develop
    • 배포 전 모든 기능 병합 및 테스트 브랜치
  • feature/#issuenumber_title
    • 기능 구현 브랜치

브랜치 관리

  1. dev 브랜치 pull
  2. dev에서 issue명으로 브랜치 생성 및 checkout
  3. 기능 구현 및 개발
  4. 해당 issue 브랜치 push
  5. dev 브랜치로 checkout
  6. dev 브랜치로 해당 issue 브랜치 merge
  7. dev 브랜치에서 기능 테스트 및 정상 동작 확인
  8. dev 브랜치 push
  9. main 브랜치로 checkout
  10. main 브랜치로 dev 브랜치 merge
  11. main 브랜치에서 기능 테스트 및 정상 동작 확인
  12. main 브랜치 push

폴더 구조

Git Commit Convention

코드 관리

ESLint 와 Prettier 룰을 팀원끼리 합의하여 정하고 사용

.eslintrc.json

{
  "env": {
    "browser": true,
    "node": true,
    "es6": true,
    "commonjs": true
  },
  "extends": ["eslint:recommended", "react-app", "plugin:prettier/recommended"],
  "parserOptions": {
    "sourceType": "module",
    "ecmaFeatures": { "jsx": true }
  },
  "overrides": [
    {
      "files": ["**/*.stories.*"],
      "rules": {
        "import/no-anonymous-default-export": "off"
      }
    }
  ]
}

.prettierrc

{
  "printWidth": 100,
  "tabWidth": 2,
  "bracketSpacing": true,
  "semi": false,
  "singleQuote": true,
  "endOfLine": "auto"
}

Issue, PR 규칙

Issue

작업 시작하기 전, 팀원들이 어떤 작업을 하는지 서로 알 수 있도록 Issue 를 올린다.

Issue 제목 작성

Issue 의 제목의 경우, 아래 Issue Prefix를 활용하여, 제목을 작성한다.

예시 : feat: 좋아요 기능 추가

Issue Prefix

Issue 내용 작성

  • 개발 시작 날짜
  • 목표 완료 날짜
  • 작업 내용 : 작업할 내용에 대해 작성한다.

PR 및 코드리뷰

기능 구현 이 후, 구현한 기능이 무엇인지, 구현 시에 이슈나 제안사항 등의 내용을 작성하여 PR을 올리고, PR에 APPROVE 가 2개 이상일 시, develop에 merge

PR 제목

PR 역시, Issue에서 사용한 prefix를 이용.
관련 이슈 내용이 잘 드러날 수 있는 제목을 사용.
예시 :feat: 모달을 열었을 때 바깥쪽 스크롤을 막는 기능 구현

PR 내용

  • 이슈 번호 : 해당 PR과 관련된 이슈 번호를 링크.
  • 작업 내용(자세히) : 코드 리뷰를 하는 팀원을 위하여, 작업 내용을 최대한 자세히 적기
  • 구현 날짜
  • 어려웠던 점 : 구현 중 어려웠던 점, 발생한 버그, 제안 사항 등을 작성.

진행 상황 공유

해당 사항들의 진행상황은 Notion 의 스크럼 보드에 기록하였다.

러북을 하게 된 이유

처음에는 간단한 주제를 정하던 중 도서관련 주제를 해보면 좋지 않을까 하여 시작하게 되었다.
그러던 중 책을 좋아하는 사람, 책을 읽고 싶지만 무엇을 읽어야 하는지 고민인 사람도 모두 접근성을 가질 수 있는 방법을 생각하게 되어 책 내용안에 마음에 드는 문구를 적어서 추천해주면 어떨까라는 생각을 하게되었다. 그 후 팀원들끼리 회의를 하고 게시글에 문구를 보여주어 책에 관심도를 높이자라는 아이디어를 떠올리게 되며 러북이라는 프로젝트를 시작 하게 되었다..!

프로젝트 회고록

🔥 Keep

  • 기획

    • 처음 기획한 기능의 대부분을 구현했다.
    • 기획하며 필요한 사항들
      기획을 하면서 기능 구현에도 목표를 두었지만 정말 이것이 하나의 플랫폼이라 생각하고 근본적으로 무엇을 위해 이 주제를 정하고 어떤 사용자를 위해 만드는 건지에 대해 확실한 목표성을 가지게 되었다.

  • 프로젝트 관리

    • 각자의 진행 상황 공유와 이슈 기반 개발이 잘 이루어졌다.
    • 프로젝트 계획, 세부 사항, 파일, 피드백을 일원화하여 관리가 되었다.
    • 스프린트를 2일 주기로 짧게 잡아 진행을 하면서 프로젝트 진행을 더욱 원활하게 하였다.
    • 노션을 이용해서 회의록을 작성하고 여러 안건들을 문서화했다.

  • 코드리뷰

    • 당연하지만 버그를 조기 발견할 수 있었고 컨벤션을 준수할 수 있었다.
    • 중복 코드 방지와 일관된 스타일을 유지할 수 있도록 되었다.
    • 다른 사람의 코드를 보게 됨으로써 프로젝트의 구조와 다른 사람의 코드 로직에 대해 더 잘 알게 되었다.

  • 팀 문화

    • 배려하는 모습 서로 의견이 겹치거나 그런 모습이 있을 때 초반에는 서로의 주장이 강해 이해를 못해주는 모습이 간간히 보였으나 프로젝트가 진행하면서 서로 존중하고 어떤 안건이 있을 때 자신의 생각보다 프로젝트를 위해, 팀을 위해 먼저 다른 사람의 말을 들어주려 하는 문화가 자연스럽게 생기게 되었다.
    • 스크럼의 중요성 프로젝트를 진행하면서 놓치지 말자고 서로 다짐했던 것 중 하나는 스크럼을 활성화 하는 것이다. 코어타임이 시작하기 전 시작 스크럼, 끝나기 전 종료 스크럼을 진행 해서 어제 진행 상황과 문제 해결, 의견 제시를 할 수 있는 시간이 항상 생겼고 끝나기 전 스크럼으로 오늘 무엇을 했고 기한 내 진행 상황에 차질이 생길 시 다른 팀원들도 바로 알고 진행이 원활하게 되었다

  • 커뮤니케이션

    • 소통의 원활화 팀의 의사결정 부분을 회의를 통하여 계속해서 결정하였고 각자의 생각을 공유하고 같이 해결을 해나가는 경우가 많았기에 프로젝트를 하면서 나 혼자만 하는게 아니라 다른 사람과 함께 진행 할때의 차이점을 배웠다. 서로의 코드를 확인하며 개인이 아닌 우리의 코드를 만들게 되었다.
    • 슬랙 만약 빠르게 공유되거나 처리되어야 할 문제가 있다면 슬랙을 통해서 신속하게 공유했다.
    • 노션
      • 노션의 ‘칸반보드’를 이용해서 현재 태스크, 앞으로 할 태스크를 모두가 공유했다.
      • 안건 페이지를 따로 만들어 급한 문제 처리, 이슈 등에 대한 원활한 소통이 이루어졌습니다.

🔥 Problem

  • 기획
    • 디테일의 부족 기획을 할 때, 세세한 기능을 생각하지 못했다는 점이 아쉽다. 특히나 기획만으로 기능을 구체화 할 때는 그 기능을 위한 숨은 의존성에 대해서 통찰하지 못했다는 점이 아쉬웠고 따라서, 기능을 구현하면서도 그 기능을 구현하기 위하여 다른 부분을 다시 회의하고, 다시 이야기하는 과정에서 시간을 많이 소요하게 되었다.
  • 개발
    • 개발 기능의 분리 개발에 있어서, 의존성이 있는 부분을 한 사람이 맡아서 개발하는게 더 좋을 것 같은데 이러한 역할 분리가 미숙하여서 의존성이 있는 부분을 여러 사람이 맡는 일이 생겼고, 따라서 개발해야할 기능이 모호해지고, 개발 시 혼란스러워지는 점이 있었다.
    • 코드에 대한 고민
      • 처음 시작 할 당시에는 코드의 재사용, 가독성, 함수명, 변수명 등에 대해 리뷰를 달며 진행하였지만 마감 기한이 다가올수록 동작에 대한 구현에만 초점을 두게 되었다.
    • 구현하지 못한 요구사항
      • 구현 내용이 복잡하기 때문에 기본 요구사항 중 알림 에 대한 부분을 충족시키지 못하였다.
  • UI/UX 디자인
    • 구체화의 중요성 와이어 프레임으로 진행을 하면서 세세하게 페이지 이동을 해야하는 부분을 놓치거나 모달이나 흐름을 구체적으로 정하지 못하여 진행을 하면서 임의로 정해야 하는 부분들이 꽤 있었기에 개발을 하면서 이 부분에 대해 또 정해야 할 시간이 필요하게 되었다.
  • 코드리뷰(PR)
    • 짧은 시간의 아쉬움 시간이 지날 수록 코드 리뷰에 들이는 시간을 짧게 할 수 밖에 없어서 코드를 꼼꼼하게 볼 수 없었다. 그래서 코드를 대강 확인하고 approve 해버리는 바람에, 이 후에 머지된 코드에서 바뀐 부분을 파악하지 못해서 시간을 들일 때도 있었다.

🔥 Try

  • 기획
    • 명확한 세부 프로세스를 설정하고 시작해야 한다. 명확한 타겟층과 사용자의 필요성을 바탕으로 주요 기능들과, 로고, 색상, 그림자 그리고 와이어 프레임이 나오며 그러한 세부 스텝을 설정하여 시작을 하면 개발이 더욱 원활히 이루어질거라 생각한다.
  • 협업(개발)
    • 이슈를 다른 툴로 연동하여 다른 사람의 히스토리를 파악하자 PR과 이슈가 연동되지 않아 한번 더 수정을 해줘야 하는 경우가 있었는데 이 부분은 나중에지라나 다른 툴로서 이슈마다 git commit을 연동하여 다른 누군가가 히스토리를 더 빨리 파악할 수 있도록 하면 좋겠다.
    • 디자인에 사용되는 색상 등은 미리 상수화를 하고 시작하자. 색상을 미리 상수화하고 시작하였기 때문에, 마지막까지 모든 파일에 색상에 대한 상수화가 적용되지 않았다. 따라서 다음부터는 대략 정해진 것이라도 미리 상수화를 한 후, css에 적용을 목표로 하자.
  • UI/UX 디자인
    • 사용자의 다양한 접근성을 위해서 반응형이 필요하다.
      구현을 하면서 반응형을 놓쳤기 때문에 이 부분을 리팩토링하여 페이지의 크기가 달라지더라도 그에 따라 변경되는 안정적인 서비스를 보여주고 싶다.
    • 사용자 액션에 따른 디테일한 view를 보여주자. 당장 눈에 보이는 컴포넌트 뿐 아니라 사용자 행동에 따른 view도 디자인 기획단계에서 신경을 써야했다. 예를 들어 글을 삭제할 때 ‘글을 삭제할까요’ 라는 한번 더 confirm을 하는 컴포넌트도 개발 중간에 발견하게 되었다. 이 부분을 급히 추가하기에는 시간이나 기술적 어려움이 있어 web API로 대체하였는데, 직접 컴포넌트를 구현하여 이 부분을 보완을 시켜야 한다.
  • 코드리뷰
    • 시간을 정해서 리뷰하는 시간을 가지자.
      시간에 쫒겨서 기능에 크게 문제가 없다면(50~70% 정도 만족한다면) 승인하고 넘어갔는데, 조금 더 리뷰를 빡빡하게 (70% 이상) 하고 코어타임을 시작하기 전에 리뷰를 하는 시간을 고정 시켜서 온전히 리뷰에 집중할 수 있도록 만들어야 겠다.

리팩토링 목표

  • 프로젝트 구조
    • components/domain 폴더의 모호성 해결과 구분
  • 재사용성을 위한 컴포넌트 분리
  • 변수들 상수화
  • 버그들 Fix
    • ex) 사용자 페이지에서 게시물 삭제/사용자 정보 수정 시 게시물에 대한 렌더링이 안됨
  • typescript로 마이그레이션 해보기

느낀 점

드디어 프로젝트가 끝이났다..!! 하지만 끝났다는 생각보다 프로젝트를 진행하며 어떤 부분이 부족했는지 어떤 부분을 공부하고 싶은지 생각이 많이 나고 그 부분들 보완하여 다음 프로젝트를 들어가고 싶다는 생각이 있다😊 (기대반걱정반...)
프로젝트를 하면서 아쉬운 부분도 많았고 배운 점도 많았기에 짧은 기간동안 힘들었지만 너무 보람찼던 프로젝트 기간이라고 느끼고 있다.
API는 아마 11월 까지 인걸로 알고 있지만 팀원들과 회의를 통해서 다시 API 작업을 하지 않을까 싶다. 얼른 공부해서 다음 프로젝트 준비하자 화이팅!

profile
5taecoo
프론트엔드를 꿈꾸며 개발을 공부 합니다.
이전 포스트

[LUVOOK] 프로젝트 DAY-16

0개의 댓글