[원티드 프리온보딩 프론트엔드 인턴십 8기] Week 1-1

✍  회고

선별과제를 어떻게 진행하는지 설명해주셨는데 개인이 작업해서 Best Practice를 뽑아서 하나의 프로젝트로 제출을 하는 방식이라고 하셨다. 살짝 모호한 부분이 있는 것 같긴 했다.

 

개발자의 기본 덕목인 GIt & Github사용시 지켜야할 컨벤션 정하는 방법과 merge 방법에 대해 설명해주셨는데 오기전에 팀 프로젝트 기획을 진행하면서 많은 자료를 찾아봤었고, 부트캠프 내 프로젝트에서 정한 컨벤션과 알려주신 것이 다르지 않았다.

 

ESLint와 Prettier, Git hookt, Husky에 대해서 강의를 해주셨는데 ESLint와 Prettier는 프로젝트에서 많이 사용했기 때문에 ESLint는 코드를 분석하여 일관적인 코드 규칙을 적용할 수 있고, Prettier는 코드의 포맷팅 스타일을 공유할 수 있도록한다.
ESLint는  Lintting, Prettier는 Code Formatting이라고 한다.

 

Husky

• 개인이 매번확인해서 ESLint와 Prettier를 확인해서 실행하는 것은 실수가 발생할 여지가 있는데 이것을 해결하기 위해 자동화를 통해서 신경쓰지 않아도 자동으로 적용이 되게하고 특정 상황에서 강제로 적용이 되게 해주는 것이다.
• commit된 코드는 무조건 formatting 되어야 하며, push된 코드는 무조건 ESLint가 pass된 상태에서 push 할 수 있도록 자동화 시키는 것이다.
• githook을 도입해서 사용할 수 있다.

githook

• git에서 특정 이벤트가 발생하기 전, 후로 특정 hook을 실행할 수 있게 하는 것이다.
• git hook 설정을 도와주는 npm package - Husky

 

팀 과제 회의 안건

• 팀장 정하기
• 팀 레포 만들기
• ESLint, Prettier, Husky 설정
• 커밋컨벤션
  • 커밋컨벤션은 복잡하지 않게 기본 설정으로
  • 커밋컨벤션 규칙
    • feat : 새로운 기능 추가
    • fix : 버그 수정
    • docs : 문서 수정
    • style : 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
    • refactor : 코드 리팩터링
    • test : 테스트 코드, 리팩터링 테스트 코드 추가(프로덕션 코드 변경 X)
    • chore : 빌드 업무 수정, 패키지 매니저 수정(프로덕션 코드 변경 X)
    • design : CSS 등 사용자 UI 디자인 변경
    • comment : 필요한 주석 추가 및 변경
    • rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
    • remove : 파일을 삭제하는 작업만 수행한 경우
    • !BREAKING CHANGE : 커다란 API 변경의 경우
    • !HOTFIX : 급하게 치명적인 버그를 고쳐야 하는 경우본문과 꼬리말은 생략 가능타입의 첫 글자는 소문자로 작성
    • 콜론 앞뒤로 한칸씩 띄워서 작성
    • 제목은 고유어를 제외하고 한글로 작성
    • 타입 : 제목 본문 꼬리말

다음 회의 준비사항

• 자기 코드 설명. 좋았던 부분과 어려웠던 부분.