프론트엔드 협업은 어떻게 할까?

SOPT·2023년 1월 24일

커뮤니케이션 협업

web

목록 보기

6/7

👨🏻‍💻프론트엔드 협업은 어떻게 할까?👩🏻‍💻

🗓️기능분석,개발 일정 및 리소스 배분

📝구현 기능 분석

요리를 개발할 때 재료가 얼만큼 들어가고 조리를 어떻게 해아하는지 레시피를 꼼꼼하게 적는것 처럼,

개발을 할 때에도 구현 기능을 꼼꼼하게 살펴보고 무엇을 개발해야하는지 문서화 해놓는것이 굉장히 중요하다.

기획자 및 팀원들과 충분한 상의를 통하여 어떤 기능을 구현해야하는지 서로가 '명확하게' 알고 있는것이 중요하다!!

예시:

🙋🏻‍♂️ 프론트 엔드 : 적용했으면 하는 차트 라이브러리가 있을까요?!

🙋🏻‍♀️ 기획자 : 기존에 OOO사이트에서 사용했던 라이브러리를 사용해주세요!

🙋🏻‍♀️ 디자이너 : 차트 라이브러리 사용하면 커스텀 할 수 있는 부분이 어떤게 있을까요?!

🙋🏻‍♂️ 프론트 엔드 : 색상, 텍스트 크기, 라벨 등등 가능합니다!

🧑🏼‍💻 백엔드 : 날짜데이터 전달해 드릴 때 문자열 '2022-12-01' 이런식으로 드리면 되나요?!

🙋🏻‍♂️ 프론트 엔드 : 아뇨! 년,월,일 로 나누어서 객체형식으로 나누어서 숫자형식으로 보내주세요!

이렇게 대화를 통해 결정된 부분들을 문서화를 통해 정해놓는다면 혼란스러움을 방지할 수 있다!

서로의 입장을 이해해 주면서 최대한 정중하고 이해하기 쉬운 용어를 이용해서 대화하는것을 지향한다!

이렇게 상의를 통해 얻은 결론들을 프로젝트 가장 상위 디렉토리에 REQUIREMENTS.md를 통해 문서화하거나,

팀원들과 상의 하여 문서화하길 바란다!

📆개발일정

위에서 작성한 구현 기능 분석한 문서를 통해 각 기능별로 소요 기간을 분석한다. 기간은 3가지로 나뉜다!

Best : 기능 구현만 하고 어떠한 돌발상황이 발생하지 않았을 때 예측되는 소요시간
Normal : 일상적으로 예상할만한 변수를 반영한 소요시간 (디버깅, pr리뷰 피드백 반영,기획자 피드백)
Worst : 돌방상황들이 겹쳐 최악의 상황에서 걸리는 소요시간(팀원의 중도포기, 등등)

이 중 Normal과 Worst 사이로 개발 기한을 설정한다.

핵심기능 단위로 중간 점검일을 설정해, 일정대로 개발이 이뤄지고 있는지 확인하며 개발을 진행한다.

📚리소스배분

리소스 배분을 하면서도 팀원의 실력, 개발자의 인원 수, 기능의 수준에 따라서 고려해야할 사항이 많다.
배분 기준에는 다양한 요건이 있지만 '구현 기능'을 중심으로 진행한다!
예시를 알아보자!

진행 순서에서 우선순위가 높은 기능을 먼저 나눈다.
기능은 가능하면 독립적으로 구현할 수 있도록 나눈다.
어려운 기능이 있거나, 처음 접해보는 기능이라면 페어코딩을 한다.

🖥️ 작업환경 설정

자 이제 본격적으로 개발을 시작하자!!??

....

잠깐!!!

아직 설정해야할게 남아있다!!

npm ?? yarn??

npm, yarn 모두 노드(Node.js)의 패키지 관리자.
npm과 yarn을 통해 다양한 패키지를 설치 및 삭제가 가능하다.

왜 패키지 관리자가 npm yarn 두개나 있고 어떤걸 선택해서 개발을 진행해야할까?

npm과 yarn을 비교하는 대표적인 2가지를 알아보자.

속도

npm은 패키지를 설치할때 한번에 하나씩 순차적으로 설치하는 반면 yarn은 여러 패키지를 동시에 가져오고 설치하도록 최적화 되어있어 패키지 설치 속도 측면에서 우월하다!
```
-   npm - 3.572 seconds
-   yarn - 1.44 seconds<br>
```
하지만 npm V6.10.1과 yarn V1.17.3으로 install 속도 실험을 하였는데,

yarn이 승리하였지만 그 차이는 아주 근소한 차이라고 하여서, 이제는 거의 차이가 없어졌다고 볼 수 있는 문제인거 같다!
보안

yarn은 보안 측면에서 npm보다 더 안전한 것으로 알려져 있다. npm은 자동으로 패키지에 포함된 다른 패키지 코드실행을 허용한다. 이로 인해 보안 시스템에 몇 가지 취약성이 발생할 수 있다. 반면에 yarn은 yarn.lock or package.json에 있는 파일만을 설치한다.

npm이 yarn보다 아직까지는 점유율이 높고, yarn은 사람들이 관심을 더 가지고 있는 패키지 매니저 로서 팀원들의 취향을 이야기 하면서 개발을 진행하면 될거같다.

Prettier & ESlint

남이 해놓은 초기환경에 숟가락만 얹으려하니 이번 합동세미나 협업에서 식은땀이 줄줄 났던적이 있다.

따라서 Prettier와 ESlint 팀원과 설정할 때 옵션을 어느정도 아는것도 중요하다고 생각이 든다.

Prettier

정해진 규칙에 따라 자동으로 코드 스타일을 정리 해주는 도구이다.

각자의 코딩스타일 취향이 다르기 때문에 협업을 할 때에는 명확한 규칙이 존재해야한다!

코드 스타일을 옵션을 통해 지정하여 팀원들이 보다 일관성 있는 코드를 작성할 수 있다!

설치 :

yarn add -D prettier

.prettierrc.js의 속성 중 자주 사용하는 속성을 알아보자

{
  semi: true,
  printWidth: 120,
  endOfLine: 'auto',
  singleQuote: true,
  useTabs: false,
  tabWidth: 2,
  trailingComma: 'all',
  arrowParens: 'always'
};

semi: true - statement 마지막에 세미콜론을 찍음
printWidth: 120 - 선호되는 한 줄의 길이
endOfLine: 'auto' - 파일의 마지막에는 EOL을 보장
singleQuote: true - 쌍따옴표가 아닌 홑따옴표를 사용
useTabs: false - 탭을 사용하지 않고 스페이스를 사용
tabWidth: 2 - 탭을 할 경우 2 스페이스
trailingComma: 'all' - 여러줄로 나뉘었을 때는 쉼표를 사용
arrowParens: 'always' - 화살표 함수에서 괄호 사용 의무화

더 많은 설정은 공식문서를 참고하길 바란다.

ESlint

정해진 규칙에 따라 코드 퀄리티를 보장하도록 도와준다.

~~이게 머선 말이고?? prettier랑 똑같은거 아이가!~~

기능을 구현할 때에는 굉장히 많은 방식이 존재한다.

함수를 구현할 때에도 function키워드를 사용하는 방법과 arrow function을 사용해서 구현하는 방법이 있다.

객체의 반복문을 사용할 때에는 for문을 사용할 수 있고, 내장 함수를 사용할 수 있고 등등 다양한 방법이 존재한다.

이렇게 협업을 하게 되면 우리가 협업에서 추구하는 '한사람이 코딩을 한것처럼 코딩하자'의 목적에 점점 멀어지게 된다.

따라서 일관성 있는 방식으로 구현할 수 있도록 잡아주는것이 eslint가 하는 역할이다!

설치 :

yarn add -D eslint + 익스텐션 설치(필수)

eslint 공식문서에 나와있는 예시를 보자!

{
    "root": true,
    "plugins": [
        "@typescript-eslint"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "rules": {
        "@typescript-eslint/strict-boolean-expressions": [
            2,
            {
                "allowString" : false,
                "allowNumber" : false
            }
        ]
    }
}

root

default : true

false의 경우 해당 프로젝트 디렉토리 뿐 아니라 해당 PC의 root 디렉토리까지 eslint를 찾는다.
extends

eslint rule 설정이 저장되어 있는 외부 file을 extends 하는 부분이다.

위의 예시처럼 extends에 eslint:recommended,plugin:@typescipt-eslint/recommended를 장착하면, 사용하려는 해당 plugin에서 기본적으로 제공하는 rule set이 적용된다.
plugins
- eslint-config-airbnb-base: 에어비엔비 린트 플러그인
- eslint-config-next: Next.js 전용 린트 플러그인
- eslint-plugin-react: 리액트 전용 플러그인
- eslint-plugin-prettier: 린트 위에 사용할 프리티어 플러그인
- eslint-config-prettier: 요건 린트 설정과 중복되는 부분이 있으면 프리티어 룰에서 제외하는 플러그인
- @typescript-eslint/eslint-plugin: : 타입스크립트 전용 린트
  등등 다양한 종류가 존재한다.
rules

직접 lint rule들을 커스터마이징 하는 부분이다.

extends로 자동으로 설정된 rules 중, 특정 rule을 끌 수 있다.

어떤 설정을 어떻게 해야하는지는 공식문서에 상세하게 나와있기때문에 팀원과 상의하여 정하면 된다!
parser

각 코드 파일을 검사할 parser를 설정하는 부분이다.

특정 @typescript-eslint/eslint-plugin 처럼 특정 플러그인을 사용한다면 해당 플러그인에서 제공하는 parser를 장착하면 된다.