개발자의 기본기 | Git & GitHub, ESLint, Prettier, husky, Git hook, Agile

• Week 1-1. 프로젝트를 하기 전 알아야 할 팀으로 일하는 법, 개발자의 기본기Git & GitHub, ESLint, Prettier, husky, Git hook, Agile
  • 선발 과제 피드백
  • Git & GitHub을 사용하면서 지켜야 할 것
  • ESLint와 Prettier, Git hook을 이용한 팀의 능률 올리기
  • Agile이란?
  • [아하!모먼트] Agile이 필요하다고 느낀 순간

---

 

- Git & GitHub을 사용하면서 지켜야 할 것

: (내용이 길어져서 따로 게시글을 팠다.)

https://proprotrainee.tistory.com/199

[ Git ] Git / Github 질문에 대한 짧은 생각 + Git 관련 인터뷰 질문 40가지에 대한 답변

 

 

- ESLint와 Prettier, Git hook을 이용한 팀의 능률 올리기 -

ESLint : 코드퀄리티를 보장해주도록 도와주고, 

Prettier: 코드 스타일을 깔끔하게 or 통일되도록 도와줍니다.

 

ESLint:

특정 기능을 구현할 때, 그 기능을 구현하기 위한 방법이 다양하게 있는데 프로젝트 전반적으로 그 방법들을 동일하게 구성하게 돕는 도구입니다.

Prettier:

구현 방법보다는 코드 자체의 모양새를 잡아줍니다. 줄 바꿈이나 공백, 들여쓰기 등등 전체 텍스트가 통일성 있게 보이도록 돕는 도구입니다.

 

 

ESLint 설치 

 

1) yarn이나 npm으로 ESLint(Library)설치

2) 사용하는 코드에디터에서 ESLint Extension 설치

 

: ESLint라는 도구가 프로젝트 코드 레벨에서 사용된다기보다는 에디터에서 적용해서 사용되는 것이기에 ESLint library와 ESLint Extension모두 설치 및 셋팅되어 있어야 정상적으로 사용 가능합니다.

 

3) .eslintrc파일을 이용해 lint rule을 셋팅합니다.

: 여기서 파일 구조는 

: root: 해당 프로젝트에서 ESLint를 어디에서 가져올지

: plugins: 다양한 종류가 있는데, 에어비앤비 린트 플러그인, Next.js 전용 플러그인, React전용 등등 설정해줍니다. 각 플러그인들은 npm, yarn 등으로 설치 가능

: parser: 각 코드 파일을 검사할 파서 설정 부분, 보통 해당 플러그인에서 제공하는 parser 장착

: extends: eslint rule에 저장되어 있는 외부 file을 extends하기 위함.

: rules: 약간 핵심. lint rule을 직접 적용하게 하는 부분

 

: ESLint 라이브러리와 익스텐션은 환경을 셋팅하는 모듈의 느낌이다.(물론 기본 lint rule은 제공) 그러므로 실제 코드 검사를 돌리고 싶은 Lint 플러그인을 별도로 설치해서 eslintrc파일에 장착시켜줘야 사용가능하다고 합니다. 

 

Prettier 셋팅 방법

1. 별도의 Prettier 플러그인을 npm이나 yarn으로 직접 설치 후에 eslintrc에 셋팅합니다.

: .prettier 파일 이용해서 규제 설정이 가능합니다.

 

2. VSCode의 prettier extension을 설치합니다.

: VSCode의 Settings에서 설정 가능합니다.

: 이 때 만약 .prettier파일이 존재한다면, VSCode의 Setting내용보다 파일 내용이 앞섭니다다.(VSCode 셋팅 내용 무시됨.)

 

 

( ESLint, Prettier 내용 참고 블로그. 해당 출처에서 읽은 뒤 외워서 작성한 것이므로 거의 모든 내용 발췌. )

https://helloinyong.tistory.com/325

ESLint, Prettier Setting, 헤매지 말고 정확히 알고 설정하자.

 

 

- Git Hook -

 

깃 레포지토리 안에서 어떤 작업이 일어날 때 깃이 자동실행하게 하는 작업들이 담긴 스크립트 혹은 그 실행과정입니다. 깃의 내부 작동을 커스터마이징하고 그 커스텀된 행동을 개발 라이프사이클 내부에서 실행시켜 주는 것입니다. 

 

보통 Git hook은 Commit 정책을 장려하며, 저장소 상태에 따라 프로젝트 환경을 변경헤 지속적으로 통합 워크플로우를 구현합니다. 스크립트는 무한하게 사용자 정의 가능하므로 개발 워크 플로우를 거의 모든 측면에서 자동화하거나 최적화할 수 있습니다. 코드 전반적인 실행의 통일성을 갖게 도와주는 것입니다. 

 

Hook은 Server측 레포지토리, Client측 레포지토리 모두에서 존재 가능합니다. 실행은 각각의 레포지토리 내의 Hook에 의해서만 실행됩니다.

 

커밋 전에, 후에 실행되는 일들에 대해 정의한 것을 실행할 수 있게 됩니다. 

 

Git Hooks에 대한 개념 정립 도운 글

https://www.atlassian.com/git/tutorials/git-hooks#:~:text=Git%20hooks%20are%20scripts%20that,in%20the%20development%20life%20cycle.

 

 

Husky

npm모듈로써 Git Hook을 보다 간편하게 사용하게 도와주는 라이브러리이다. Git Hook를 사용하게끔 강제해줄 수 있다.

Husky를 설치하고 정책을 정의하면 자동적으로 Git Hook이 사용되는데, Git hook이 설치된 .git/hooks안에 husky 동작 코드가 생성되고 업데이트되기 때문이다.

설치 후에 pre-push, pre-commit 등 다양한 정책을 선언하고 명령어로써 사용할 수 있게 된다.

정책 내용은 pre-commit에 prettier로 코드를 정리하게 한다던지 등등 정말 다양하게 사용자 정의 행동을 선언할 수 있다. 

 

Husky에 대한 이해를 도운 글

https://library.gabia.com/contents/8492/

가비아 라이브러리

 

 

- Agile이란? -

 

하나의 프로젝트를 작업 순서대로 쭉 진행하는 것이 아니라, 짧게 끊어가며 산출물을 최대한 빠르게 내고 피드백을 받아 다시 수정하는 식으로 사이클을 반복해서 진행하는 프로젝트 개발 기간 구성 방식입니다.

프로젝트를 작은 단위로 쪼개서 각각 수행되며 주기적인 피드백과 그로 인한 반복되며 업데이트 되는 것이 핵심입니다.

 

보통 폭포수 모델과 비교됩니다. 폭포수 모델은 전체 프로젝트를 작업 순서대로 진행하는 개발 방식을 의미합니다. 단계별로 진행되기 때문에 프로젝트 구성과 취합 등에서 단순하게 적용된다는 장점이 있습니다. 다만, 갈수록 서비스 배포 속도가 빨라지고 중요해지며, 돌발 상황에 의한 변동 등에 취약합니다. 처음부터 전체 설계, 팀 구성부터 다시 진행해야만 하기 때문입니다. 만약 마지막 릴리즈 단계에서 오류가 생기거나 반려된다면 수정이 어렵습니다.

 

반면, 애자일 모델은 빠르게 마지막 단계까지 진행하므로 전체 작업에 대한 피드백이 빠르고 이 피드백을 기반으로 업데이트를 반복해서 진행할 수 있습니다. 때문에 프로젝트 전반적인 수정이 쉽고 프로젝트 퀄리티나 안정성을 더 보장받을 수 있습니다. 각 개발 팀의 산출물 취합이나 프로젝트 구성 측면에서 폭포수 모델보다는 복잡하며 이러한 설계 과정이나 피드백 과정들이 더해지므로 폭포수 모델보다 전체 프로세스가 느려보일 수 있습니다. 하지만, 폭포수 모델에서의 오류 사항을 조기에 수정해나가기 때문에 전체적인 관점으로 볼 때 더 빠를 수 있습니다. 가장 큰 장점인 고객 측에서 목업 확인을 빠르게 할 수 있다는 점이 더해지며 최근에는 주요 개발 방식으로 여겨지고 있습니다. 

 

 

 

하단 링크는 애자일에 대해서 아틀라시안 측에서 배포한 설명인데, 개발 관리/설계 시스템과 관련된 서비스들을 제공하는 회사라 그런지 되게 깊이 있게 설명이 나와 있습니다. 제가 설명한 것보다 깊은 이해가 가능합니다. 

https://www.atlassian.com/agile#:~:text=Agile%20is%20an%20iterative%20approach,small%2C%20but%20consumable%2C%20increments.

What is Agile? | Atlassian

 

 

- Agile이 필요하다고 느낀 순간 -

 

개인적으로 최근 GoodGeul이라는 책 기록 웹 어플리케이션을 만들어보고자 도전했을 때, 개인 프로젝트임에도 애자일 방식 같이 구성했으면 속도가 올랐을 것이라는 생각이 들었다. 일단 개발 계획부터가 부실했는데 이걸 단계단계 차례차례 나가다보니까 어떤 것 하나에 오류가 생기거나 지식의 공백으로 새로운 것을 배워와야 할 때 시간이 너무 딜레이되었다. 전체적인 큰 틀을 잡고 해결한 뒤에 수정, 수정, 하며 고쳐나갔다면, 진행이 루즈해지지 않았을 것이라고 생각된다.

학교에서의 다른 팀 프로젝트 역시 비슷했다. 한 기능에 여러명이 같이 작업하고 먼저 수행한 사람의 작업물로 프로젝트를 메꾸고, 누군가의 작업이 끝나야만 그 때 시작하고 이러니 진행이 더뎠다. 학생들이므로 친숙하지 않은 내용을 공부해가며 사용해야 해서 애자일 같은 개발 방식을 채택할 여력이 없었다는 것이 안타깝다. 각자의 숙련된 기술로 개발한 결과들을 합쳐가며 빠르게 프로젝트를 진행해야할 때 더 많은 소통과 합의가 이루어질 수 있는 좋은 프로그래밍 프로세스 방식이라고 생각된다. 꼭 실제적인 프로젝트에서 사용하기를 기대한다.