패키지를 처음 만들고 README 작성을 많이 놓칩니다.

• 사내 프로젝트 중에서도 그런 경우가 많이 있습니다.
• 문서화는 굉장히 중요합니다.
• 모르는 사람이 프로젝트를 봐도 어떤 테크 스펙, 어떤 목적, 누가 포함되어 있는지 나와 있어야 합니다.
• 그래서 리드미를 제일 먼저 작성해야 합니다.

리드미에 넣어야 하는것?

1. 참여자(Contributor): 사람이 많아질 수록 중요합니다.
2. 기술 요구사항(기술 스택): 사용되는 기술들을 나열해줍니다.
3. 도커(Docker): 도커를 어떻게 사용하고 있는지 작성해줍니다.
4. 스크립트(Script): CLI 명령어들 정리해줍니다.

바벨(Babel) 설정이 필요한 이유?

• 우리가 다루는 자바스크립트 문법은 ES2015 이상이기 때문에 오래된 브라우저에게 적용하기 위해서 사용합니다.
• 신규로 완전히 최근에 나온 스펙들을 사용시 빌트인 시점에 지원을 안하는 경우가 있어서 가급적으로 바벨 설정을 해주는 것이 좋습니다.

바벨 설정법

• Next.JS 공식문서 참고
• $ npm run dev 를 미리 실행시켜준 후 바벨 설정 해주면 바로 빌드하고 ~/.next/server/pages/_app.js 등에서 빌드된 파일 확인 가능합니다.
• 바벨 설정이 완료되면 개발 준비는 어느정도 마무리 되었다고 할 수 있습니다.

ESLint 설정 개요

• ESLint 에 아무것도 설정을 하지 않고 개발을 진행하다 보면 나중에 동료들과 어떤 규칙, 방법으로 개발을 하기로 했었는지가 불필요해집니다.
• ESLint 설정 또한 공식문서를 참고합니다.
• 동료들과 따옴표('')는 쓰지말자 혹은 쌍따옴표("")는 쓰지말자 등의 규칙을 정하고 ESLint 설정해줘서 코드의 일관성을 가질 수 있습니다.

ESLint 설정법

• 모든 규칙들을 일일히 다 설정하면 시간이 많이 걸리기 때문에 ESLint 설정이 이미 되어있는 기존 사이트들을 참고하면 도움이 많이 됩니다. (예, airbnb eslint typescript)
• 위와 같이 검색시 나온 npm 패키지를 다운받고 ESLint를 추가해주면 됩니다.

ESLint 설정은 그냥 규칙일뿐인거 같은데 꼭 해줘야 하나요?

• 회사는 다양한 사람들이 함께 일하는 곳이기 때문에 생길 수 있는 파편화 를 막아주는 기본적인 도구이기 때문에 사용해야 합니다.

각 회사마다 ESLint 룰이 다르기 때문에 알맞는 ESLint 룰을 사용해주면 됩니다.

ESLint나 개발환경을 세팅할때 가장 중요한점?

• 동료들과 협의가 가장 중요합니다.
• 프로젝트 내의 일관성 유지시 유지보수성을 높일 수 있습니다.
• 독단적인 ESLint 및 개발환경 설정은 안됩니다.

Github에 대한 설정

1. 프로젝트 폴더 내에 .github 폴더를 생성해줍니다.

2. .github 폴더 내에 CODEOWNERS 파일 생성합니다.

   • CODEOWNERS : Pull Request 등으로 개발을 진행할때 누가 이 코드의 관리자인지 지정해주는 파일입니다.
   • CODEOWNER 설정과 Reviewer 설정의 차이점 : CODEOWNER 설정시, 깃허브 프로텍션 룰을 따라 CODEOWNER가 리뷰를 남겼을 때만 Code Merge가 가능합니다.
   • Dockerfile 의 경우 DevOps 엔지니어를 추가해두기도 합니다.
   • API 의 경우 Backend 엔지니어

   // 간단한 설정 예시
   // ~/.github/CODEOWNERS
   
   * @HyeonWooGa