[기업 과제] Jaranda 팀 프로젝트 리뷰 ④

---

 개요

4편 작성하겠습니다. 

 

1편은 전체적인 프로젝스 소개와 저의 역할을 중점으로 작성한 회고.

https://bbangson.tistory.com/83

[기업 과제] Jaranda 팀 프로젝트 리뷰 ①

2편과 3편은 팀원이 구현한 기능에 대한 공부와 설명.

https://bbangson.tistory.com/85

[기업 과제] Jaranda 팀 프로젝트 리뷰 ②

https://bbangson.tistory.com/86

[기업 과제] Jaranda 팀 프로젝트 리뷰 ③

4편은 팀 프로젝트 셋업 내용과 리팩토링 및 최종 회고. 

이렇게 구성되어있습니다. 

 

 팀 프로젝트 리뷰 마지막 포스팅 입니다. 규모 있는 프로젝트는 아니지만 공부하다 보니 포스팅을 4개씩이나 하게 됐습니다. 나쁘다고는 생각하지 않지만, 조금 더 요약하고 핵심만 추리는 연습을 해야 될 것 같습니다. 

 

 이번편은 팀 프로젝트 셋업(개발 환경, 폴더 구조, 스타일 가이드&&컨벤션, 개발 방법)과 간단하게 리팩토링 내역과 최종 회고에 대해서 작성하겠습니다.

 

 

 

---

프로젝트 셋업

 

□ 개발 환경

 

  보통 팀 프로젝트 시작 단계에서는 팀 레포지토리를 생성합니다. 그리고 협업의 효율을 높이기 위해 몇 가지 셋업을 진행합니다. 저도 많은 경험은 아니지만 팀 프로젝트를 진행할 때, 초기 셋업에 팀원들과 적지 않은 시간을 회의한 것 같습니다. 이번 프로젝트에서 진행됐던  초기 셋업 과정을 잊지 않고, 앞으로의 프로젝트에서 더 효율적인 셋업 과정을 위해 몇 가지를 작성해보겠습니다.

 

1. 초기 설치 내역

CRA 설치 

npx create-react-app [폴더 이름]

 

React Router 설치

npm install react-router-dom --save

 

Styled Components 설치
npm install --save styled-components

 

styled reset 설치

npm i styled-reset --save

 

props-type 설치

npm i props-type

 

react-icons 설치

npm i react-icons

 

 

2. Prettier 

 Prettier는 코드를 정해진 방식대로 정렬해주는 Code Formatter입니다. 협업 시 일정한 규칙으로 코드를 정리해주는 꼭 필요한 도구입니다. 

// .prettierrc.js
module.exports = {
  // 코드 한줄이 Maximum 80칸
  printWidth: 80,
  // 코드 마지막에 세미콜론 존재 유무
  semi: true,
  // 문자열은 홀따옴표로 설정.
  singleQuote: true,
  // 들여쓰기 너비는 2칸
  tabWidth: 2,
  // 객체나 배열 키:값 뒤에 항상 콤마를 붙힘.
  trailingComma: 'all',
  // 탭의 사용을 금하고 스페이스바 사용으로 대체
  useTabs: false,
};

 

3. Eslint 

// eslintrc.js
module.exports = {
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:jsx-a11y/recommended",
    "plugin:import/errors",
    "plugin:import/warnings",
    "plugin:react-hooks/recommended"
  ],
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "plugins": ["react"],
  "rules": {
    "import/extensions": "off",
    "no-use-before-define": "off",
    "react/jsx-filename-extension": ["error", { "extensions": [".js", ".jsx"] }],
    // 이거 추가해주면 안쓰는 변수 오류 없앨 수 있다.
    "no-unused-vars":"warn"
  },
  "settings": {
    "react": {
      "version": "detect"
    },
    "import/resolver": {
      "node": {
        "paths": ["src"],
        "extensions": [".js", ".jsx"]
      }
    }
  }
}

 Eslint는 딱히 규격을 정했다기 보다 기존에 있는 특정 기업의 eslint파일을 가져왔습니다. eslint 설정 방법과 속성을 따로 공부가 필요할 것 같습니다.

 불편했던 점이 하나 있었습니다. 사용되지 않는 변수는 오류(빨간 줄) 처리가 되어서 나타났다는 것입니다. 해결 방법은 생각보다 간단했습니다. rules key 값 안에"no-unused-vars":"warn"코드를 추가하면 됩니다. 

 

 

□ 폴더구조 

 

폴더 구조

폴더 / 파일	설명
Assets	Jaran 로고 및 아이콘 모음.
Components	각 Page에 자주 사용되는 컴포넌트 모음.
Modal	팝업창 Modal 컴포넌트
Pages	Route에 해당하는 Page 컴포넌트 모음
Services	공통 서비스 컴포넌트(auth, user) 모음. auth.js - 로그아웃, 로그인 상태, 관리자 확인 user.js - 유저 관리 함수 모음.
Utils	공통적으로 사용되는 함수 및 LocalStorage 접근
App.js	public, private Route 각 페이지 관리
routes.js	public, private 권한 설정.

 

 

□ 컨벤션 / 스타일 가이드 

 

 .github 폴더 내에서 이슈 및 PR 템플릿을 작성했습니다.

템플릿

아래 내용은 이슈 템플릿의 기능 요구 템플릿입니다. 

---
name: Feature request
about: Suggest an idea for this project
title: ""
labels: ""
assignees: ""
---

## 설명

## 할 일

- [ ]
- [ ]
- [ ]

## 일정

 

아래는 PR(Pull Request) 템플릿입니다. 

## 제목

## 작업 내용

## 주의 사항

짧은 기간의 토이 프로젝트라 굉장히 간단하게 작성됐습니다. 다음 프로젝트부터는 조금 더 공부하고 세분화가 필요해 보입니다.

 

다음은 커밋 메시지 컨벤션 및 스타일 가이드입니다. 

커밋 메시지 스타일 가이드

 

아래 링크를 참고해서 컨벤션을 완성했습니다. 

https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

[협업] 협업을 위한 git 커밋컨벤션 설정하기

 

 

□ 애자일 개발 방법론

 

  이번 팀 프로젝트는 애자일 개발 방법론을 적용해서 프로젝트를 진행했습니다. 애자일 개발 방법론을 적용해서 진행해본 프로젝트가 경험이 이번이 2번째지만, 이 개념은 정말 모호한 것 같습니다. 물론 저는 현업에서 애자일 프로세스를 진행해본 적은 없습니다. 단순히 예비 개발자들끼리 모여 느낌만 본 정도입니다. 

 

 애자일 개발 방법론에 관한 포스팅을 여러개를 읽었지만 그 결과, 제가 생각한 애자일 개발방법론 한 줄 정리는 아래와 같습니다.

작동하는 기능을 신속하게 개발하기 위하여, 개발 자체에 집중할 수 있는 환경을 조성하고 각 기능을 작은 구성 요소로 나뉘어 협업을 진행하는 일종의 방법론이라고 생각합니다.

 위와 같이 생각한 이유는  문서 작성보다 기능 개발 자체에 집중하고, 체계적인 계획보다는 변화에 집중할 수 있는 환경이 개발에 집중할 수 있다고 생각하기 때문입니다. 그리고 이것이 애자일이 추구하는 가치라고 생각합니다. 그리고 긴 개발 기간을 가져가는 것이 아닌 짧은 스프린트 기간을  두고, 그 기간 안에 완성할 수 있는 가장 작은 구성 요소를 개발하는 것입니다. 그렇기 때문에,  개발자들은 각 기능 개발에 대해서 영향을 받지 않고 프로젝트를 진행할 수 있습니다. 스프린트 기간을 직접적으로 사용하는 스크럼 방법이 애자일 개발 방법론 중에서 제일 유명하다고 생각합니다. 그리고 스크럼의 효율을 최대한 끌어내기 위해 짝 프로그래밍(pair programming)도 방법론 중 하나로 떠오른 것이라 생각합니다.

 

 이 포스팅은 애자일 개발방법론에 대한 글을 작성하는 것이 아니므로, 이 프로젝트에서 애자일 개발 방법론을 적용했던 요소와 그에 관한 느낀 점만 말씀하겠습니다. 

 

1. Jira Software는 사용하지 않았습니다. 

 Jira Software는 애자일 프로젝트 관리 도구로써 스크럼, 칸반 보드를 지원합니다. 애자일 개발 방법론을 적용하여 프로젝트를 진행하면 Jira Software를 사용하는 것이 바람직하다고 생각합니다. 하지만 이번 프로젝트에서는 프로젝트 기간도 짧았고, Github Project 탭을 사용해보기 위해 사용하지 않았습니다. 개인적으로 Github Project 탭을 이번 기회에 경험해서, Jira Software를 사용하지 않은 점에서는 아쉽지 않습니다. 

 

2. 스크럼 회의를 진행하였습니다. 

 애자일 개발 방법론에서 추구하는 가치 중 하나는 변화에 대한 빠른 피드백과 팀워크입니다. 이를 만족하기 위해선 팀원들과의 매일매일 회의를 필수 불가결한 요소라고 생각됩니다. 회의 명칭을 스크럼이라고 지정하고 진행한 것은 아니지만, Daily Meet-up을 통해 서로의 진행 상황을 정리하고, 각자가 고객이 되어 피드백을 하며 변화에 최대한 빠르게 대응하도록 하였습니다. 

 

3. 짝 프로그래밍을 하였습니다. 

 짝 프로그래밍은 사실상 애자일 개발 방법론 중 하나라고 부르지 못할 만큼, 요즘 코딩 문화에서 정말 널리 알려져 있다고 생각됩니다. 하지만 팀워크를 중요시하는 애자일에서 짝 프로그래밍은 높은 효율을 보이는 방법입니다. 또한, 제가 이번 프로젝트에 굉장히 만족한 부분입니다. 짝 프로그래밍을 통해 코드에만 갇혀서 생각하던 제 사고를 더 넓힐 수 있는 계기가 됐으며, 완성도 높은 기능을 더 신속하게 개발할 수 있었습니다. 

 

 

 

---

리팩토링

 폴더 구조 및 맡았던 역할인(SignUp) 부분에 대해서 조금 아쉬웠던 부분을 리팩토링 했습니다. 

리팩토링 대상	리팩토링 이유	결과
Pages 폴더와 같은 레벨에 있는 Modal 폴더	다양하게 사용되는 Modal 컴포넌트는 자주 사용되는 컴포넌트 모음인 Components 폴더 안에 위치하는 것이 옳다고 판단했습니다.	src/Modal/ → src/Components/Modal/
SignUp.js	SignUp.js 컴포넌트의 코드가 600줄이 넘어가서 가독성이 현저하게 떨어집니다. 다양하게 사용될 수 있는 함수는 SignUp/utils 폴더에 따로 빼주기로 했습니다.	SignUp.js 안에 존재했던 inputCheck 함수와 아이디, PW 부분 validation 로직을 utils 폴더에 따로 생성함 ⇒ SignUp/utils/inputCheck.js ⇒ SignUp/utils/partValidation.js
SignUp.js	utils 폴더 안의 컴포넌트를 import 하기 위해선 각각 한줄 한줄 import 해야했습니다. -> 생산성과 가독성 떨어짐  ex) import get_address from './utils/get_address';  import inputCheck from ./utils/inputCheck;  import partValidation from ./utils/partValidation;	utils 폴더 내에 index.js 컴포넌트를 생성하여 한번에 export를 진행하였습니다.   ⇒ import { inputCheck, get_address, IdNumberOrEng, Id4OrMoreDigits, IdSpecialChar, IdHangul, PwEnglish, PwNumber, PwSpecialChar, Pw8OrMoreDigits, } from './utils'; 그 결과 여러줄로 import 해야했던게  ->  import {   inputCheck,   get_address,   IdNumberOrEng,   Id4OrMoreDigits,   IdSpecialChar,   IdHangul,   PwEnglish,   PwNumber,   PwSpecialChar,   Pw8OrMoreDigits, } from './utils'; 한 줄로 바꿨습니다.

 

 

 

---

최종 회고

 여러 번 언급한 것 같지만 객관적으로 보면 수준 높은 프로젝트는 아닙니다. 하지만 저에게 많은 의미가 있는 프로젝트였습니다. 최대한 기본에 충실할 수 있었고 쉽게 놓치고 갈 수 있던 부분을 다시 복기할 수 있었습니다. 구글링보다는 제가 생각한 로직으로 코드를 작성하려 하였습니다. 틀리더라도 제 생각을 피드백받고 싶었습니다. 운 좋게 저보다 잘하는 팀원들을 만나서 많이 배울 수 있었습니다. 짧은 기간이라 많이 친해지지는 못했지만 만약 이 글을 보신다면 앞으로의 커리어를 응원하겠습니다. 감사합니다.

 

 

 

 

 

 

 

 

 

 

 

---

 원래 3편으로 계획하려고 했지만, 공부할 것도 많고 쓸 얘기가 많아 4편이 되었습니다. 프로젝트는 총 5일 진행했는데, 무슨 일이 있던 건지 모르겠지만 포스팅은 2주가 걸렸습니다. 포스팅 내용을 요약하며 짧게 쓰는 방법을 고민해봐야겠습니다.

 

 

이번 기회를 준 wecode, Wanted, Jaranda에 감사의 말씀드리며, 여러 의견과 피드백을 댓글로 남겨주시면 감사하겠습니다. 

 

 

 

 

관련 링크

 

https://wecode.co.kr/?gclid=CjwKCAjw3riIBhAwEiwAzD3TieM0Y43D-7_T8g2QOIR2WYaykoQxaKxTgyySC8gFOwW7IMjXg_qStBoCa34QAvD_BwE 

WeCode | 위코드 | 코딩 부트캠프 | 코딩교육 | 온라인 부트캠프

https://www.wanted.co.kr/events/pre_onboarding_course_2

프리온보딩 코스_ 프론트엔드

https://jaranda.kr/index_parent

jaranda | 자란다