강력하고 응집력 있는 팀을 구축하기 위한 모범 사례
협업은 소프트웨어 개발의 성공을 위해 매우 중요합니다. 함께 잘 협력하는 강력한 팀은 더 나은 결과를 달성하고 어려움을 극복할 수 있습니다. 협업을 촉진하려면 노력과 소통, 지속적인 노력이 필요합니다.
코드 품질은 특히 장기적인 관점에서 효율적으로 작업하고자 할 때 개발 프로세스에서 매우 중요한 부분입니다. 전체 애자일 방법론을 포함하여 많은 접근 방식과 모범 사례가 있지만, 대부분은 최소 6명이 수행하는 대규모 엔터프라이즈 프로젝트와 관련이 있습니다.
다음과 같은 경우 어떻게 해야 하나요? 프로젝트 가 작거나 고객이 더 투자할 가치가 있는지 아직 잘 모르시나요? 분명히 프로젝트의 MVP 단계, 코드 스타일링이나 단위 테스트는 최우선 순위가 아닙니다. 투자자는 일반적으로 좋은 제품 작동한다면 테스트가 필요 없겠죠?
사실, 저는 다음과 같은 경험이 있습니다. 처음부터 앱 구축모범 사례를 처음부터 사용하지 않더라도 말이죠. 일부 비즈니스 상황에서는 투자자의 예산 계획과 개발자의 "있으면 좋은" 목록 사이에서 타협점을 찾아야 했습니다. 다행히도 GitHub를 사용하면 코드 품질과 관련된 대부분의 일반적인 문제를 몇 분 안에 해결할 수 있습니다.
시작하기 전에 몇 가지 가정이 필요합니다:
다음과 같은 JS 프레임워크를 사용해 본 적이 있다면 Vue 또는 React와 같은 몇 가지 공통점을 쉽게 찾을 수 있습니다:
우리가 이야기하고 있더라도 JavaScript 프로젝트에서 작업하고 있습니다. 노드 환경이 있으므로 당연히 다음과 같은 노드 항목도 있어야 합니다. package.json, package-lock.json 그리고 /node_modules 카탈로그를 루트 디렉토리에 저장합니다.
이 모든 것이 제자리에 있습니다. 컨벤션. 프레임워크는 몇 가지 합리적인 규칙을 제공하기 위해 만들어졌기 때문에 일반적으로 초기 디자인 패턴에 대해서는 신경 쓸 필요가 없습니다. 이 예제에서는 몇 가지 접근 방식을 설명하고자 하므로 Vue CLI와 같은 즉시 사용 가능한 솔루션을 적용하지 않겠습니다.
이 모든 마법의 보푸라기 스크립트 아래에 무엇이 숨어 있는지 알아볼 시간입니다!
고품질 솔루션을 제공하기 위해 새 프로젝트를 설정할 때 가장 먼저 시작해야 하는 것은 린터입니다. 두 가지 린터에 집중해 보겠습니다. 스타일용 스타일린트(*.scss) 및 소스 파일용 ESLint(*.js). 이 두 가지 린터는 모두 NPM에서 사용할 수 있으며 구성이 매우 쉽습니다. 린터를 사용하려면 설치 프로세스를 거쳐 구성 파일을 추가하고 프로젝트 스크립트를 정의해야 합니다. 단계별로 해보겠습니다.
노드 환경에서 스타일린트를 설치하는 방법은 매우 간단합니다. 에 따르면 공식 문서를 실행하기만 하면 됩니다:
엔피엠 설치 --save-dev 스타일린트 스타일린트-config-standard
를 클릭하고 완료될 때까지 기다립니다.
스타일린트 구성 표준 는 기본 린팅 규칙 세트를 제공하며 필요에 더 적합한 패키지로 대체할 수 있습니다(예. 에어비앤비 스타일). 그런 다음 새 숨김 파일을 만듭니다. .stylelintrc.json는 미리 정의된 규칙을 로드하는 Stylelint 구성 파일입니다:
{
"확장": "스타일린트-구성-표준"
}
현재 누락된 유일한 것은 SCSS 파일을 린팅하기 위해 package.json 파일에 선언된 일부 NPM 스크립트(또는 스크립트)입니다. 제 제안은 이렇습니다:
"스크립트": {
"lint:scss": "스타일린트 '**/*.scss' --syntax scss -f verbose --color",
"lint:scss:fix": "stylelint '**/*.scss' --syntax scss --fix -f verbose -color"
}
보시다시피, 저는 다음과 같은 스크립트를 선언했습니다. -fix 옵션 - 리포지토리에 변경 사항을 푸시하기 전에 사용하는 옵션입니다.
기억하세요 - 다음을 사용하는 것은 나쁜 습관입니다. -fix 를 CI 흐름에 포함하지 않으면 프로덕션에 전달하는 코드가 리포지토리에서 올바르게 스타일이 지정되지 않기 때문입니다. 그렇기 때문에 두 스크립트가 모두 필요합니다.
파일을 생성하여 린터를 테스트해 보겠습니다. /assets/scss/styles.scss 와 같은 일부 콘텐츠가 있습니다:
body {
배경색: #fff;
}
npm 실행 린트:SCSS
콘솔에 다음과 같은 내용이 표시될 것입니다:
> 스타일린트 '**/*.scss' --syntax scss -f verbose --color
assets/scss/styles.scss
2:21 ✖ 2칸 들여쓰기 예상 들여쓰기 들여쓰기
소스 1개 확인
~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss
1 문제 발견
심각도 수준 "오류": 1
들여쓰기: 1
npm 오류! 코드 엘리프 사이클
npm ERR! errno 2
npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --syntax scss -f verbose --color`
npm ERR! 종료 상태 2
이것은 실제로 린터가 작동한다는 것을 의미합니다!
출력에는 오류를 일으키는 줄이 정확히 표시되고 해결해야 할 문제가 설명되어 있습니다. 일부 문제는 개발자의 판단이 필요하기 때문에 자동으로 수정할 수 없지만 대부분의 경우 동일한 명령을 -fix 옵션이 있으므로 실행해 보겠습니다.
npm 실행 lint:scss:fix
이제 오류가 발견되지 않은 녹색 출력이 표시됩니다:
스타일린트 '**/*.scss' --syntax scss --fix -f verbose --color
소스 1개 확인
/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss
0 문제 발견
이 단계는 이전 단계와 거의 동일합니다. ESLint를 설치하고, 몇 가지 기본 규칙 세트를 정의하고, 호출 가능한 두 개의 NPM 스크립트(하나는 CI용, 하나는 프리푸시용)를 선언하겠습니다. 시작해 보겠습니다!
일상 업무에서 NPM을 사용하는 경우 ESLint를 전역에 설치하고 싶을 수도 있습니다. 그렇지 않은 경우 다음에서 설치 지침을 확인하세요. 공식 문서.
npm 설치 -g eslint
컴퓨터에서 eslint 명령을 사용할 수 있으면 프로젝트에서 이 명령을 실행하면 됩니다:
eslint --init
터미널에 표시되는 추가 지침에 따라 다음과 같이 몇 가지 프로젝트 결정을 내리세요:
이 자리에서 Prettier라는 코드 포맷터에 대해 한 마디 쓸 가치가 있습니다. 완전히 표준화되어 있으며 대부분의 코드 편집기(예: VS Code)와 호환됩니다. Prettier는 사전 정의된 코드 스타일링 규칙 세트를 많이 제공하고 린터와 함께 작동하며 코드의 최고 품질을 추구하는 데 큰 도움이 될 수 있습니다. Prettier가 정확히 무엇인지 이해하려면 다음을 방문하세요. 비교 를 공식 문서에서 가져옵니다.
완료되면 ESlint 구성 파일(예 .eslintrc.json이전에 선택한 항목에 따라 다름)가 루트 디렉토리의 .stylelintrc.json 이전에 생성되었습니다.
이제 다음에서 스크립트를 정의해야 합니다. package.json 파일과 동일합니다:
"스크립트": {
"lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
"lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}
축하합니다! 이제 ESLint를 바로 사용할 수 있습니다. 제대로 작동하는지 확인해 보겠습니다. 만들기 /src/index.js 파일에 콘텐츠를 추가합니다:
console.log("something");
린터를 실행합니다:
npm 실행 lint:js
출력은 다음과 같이 표시되어야 합니다:
> eslint '**/*.js' --ignore-pattern node_modules/
~/Codest/Projects/github-workflow-demo/src/index.js
1:1 경고 예기치 않은 콘솔 문 no-console
1 문제(오류 0, 경고 1)
이 경고는 사용 후에도 사라지지 않습니다. -fix 옵션은 린터는 잠재적으로 의미 있는 코드에 영향을 미치지 않습니다. 코드 스타일링에만 사용됩니다.공백, 줄 바꿈, 세미콜론, 따옴표 등을 포함합니다.
GitHub 워크플로 는 꽤 잘 문서화되어 있습니다. 이에 대해 더 자세히 알아보고 싶으시다면 지금부터 원격 리포지토리(물론 GitHub에서 호스팅)로 푸시한 후 코드를 린트하는 간단한 워크플로우를 구현해 보겠습니다.
만들기 /.github/workflows 디렉토리와 새 코드 품질 워크플로.yml 파일로 정의해야 하므로 GitHub 워크플로우를 YAML 파일로 정의해야 합니다.
제대로 된 워크플로를 실행하려면 몇 가지 질문에 답해야 합니다:
몇 가지 고려 사항과 몇 시간 동안의 문서 예제 작업 후 .yml 파일은 다음과 같이 보일 수 있습니다:
이름: 코드 품질
켜기: '푸시'
jobs:
코드 품질:
이름: 린트 소스 코드
실행 중: 우분투 최신 버전
steps:
- 사용: actions/checkout@v1
- 이름: 설정 노드
사용: actions/setup-node@v1
with:
노드 버전: '12.1'
- 이름: 캐시 종속성
uses: actions/cache@v1
with:
경로: ./node_modules
키: $(( runner.OS ))-의존성-$(( hashFiles('**/package-lock.json') ))
복원 키: |
$(( runner.OS ))-dependencies-$(( env.cache-name ))-
$(( runner.OS ))-dependencies-
$(( runner.OS ))-
- 이름: 설치 종속성
run: |
npm 설치
- 이름: 린트 파일
run: |
npm 실행 린트
깃허브는 우리에게 필요한 모든 환경을 제공합니다. 마지막 줄에서 다음 명령을 실행합니다. npm 실행 린트 이전에는 정의되지 않았습니다:
"스크립트": {
"lint": "npm run lint:js && npm run lint:scss"
}
워크플로에서는 다음과 같이 사용하지 않습니다. 수정 명령어를 사용합니다.
이 모든 단계가 완료되면 풀 리퀘스트를 병합하기 전에 GitHub에서 이 멋진 결과물을 즐길 수 있습니다: