원티드 프리온보딩 프론트엔드 과정을 진행하며 얻은 인사이트를 기록한 내용입니다!
개발자로서 갖춰야 할 역량은 두 가지입니다.
- 업무에 필요한 역량을 말하는 하드스킬
- 업무 효율성을 극대화 하기 위한 소프트 스킬
이라고 생각하는데요. 실제 개발자들에게 업무를 할 때 중요한 역량을 물어보면 개발 능력 외에 커뮤니케이션, 소통, 협업 능력과 팀워크를 강조한다고 합니다.
결국 개발자는 혼자서 하나의 제품을 만들 수 없기 때문인데요. 특히 제가 속한 프론트엔드 분야는 업무 특성 상 기획자, 디자이너, FE개발자, BE개발자로 구성되어 있는 팀에서 가장 많이 소통을 해야한다고 합니다.
그렇다면 소통은 어떻게 잘해야 할까요?
소통은 크게 말로 하는 소통과, 문서로 하는 소통으로 나눠집니다.
1. 말로 하는 소통
내가 상대방에게 구두로 설명하는 목적은 '상대방을 이해시키기 위함'임을 명심해야 합니다. 일반적으로 복잡한 요구사항과 코드, 로직 등을 설명할 경우가 많기 때문에 상황에 맞춰 미리 문서를 준비 또는 노트에 적어가며 시각화를 동반해서 소통하는 것도 방법중 하나라고 합니다.
2. 문서로 하는 소통
일반적으로 개발자들은 구두로 하는 소통보다 문서로 하는 '비동기'적 소통을 한다고 하는데요. '문서'라면 PDF, 노션, PPT 등이 떠오를 텐데 개발자들의 문서는 저희가 가장 많이 사용하는 commit, PR, 그리고 코드입니다.
그 동안 commit, PR, 코드를 문서라고 미처 생각하지 않고 읽기 힘들게 작성해오진 않았나 반성해봅니다.
어떻게?
저의 경우에는 옛날에 진행했던 팀 프로젝트에선 팀원끼리 컨벤션을 미리 맞추는 방법을 활용했는데요.
- 이슈
- PR
- 커밋
확실히 이런식으로 정리하니 팀원간에 어떤 작업을 어떻게 했는지 파악하기 수월했던 것 같습니다.
history..
프로젝트를 진행하며 전체 흐름을 보면 커밋의 대한 히스토리를 볼 수 있는데요. 이때 만약 commit history가 뒤죽박죽이라면 파악하기 힘들 것 입니다.
이를 깔끔하게 유지하기 위해서 Git에서는 squash 기능을 제공하는데요. 이는 여러 커밋들을 하나로 합칠 수 있습니다.
https://www.delftstack.com/ko/howto/git/git-squash-commits/
앞서 말한 팀프로젝트를 진행하며 이 방법에 대해 팀원간의 협의를 해보았는데요. 커밋별로 컨벤션을 맞추어 history가 보기 불편하지는 않았고 또 세부적으로 확인할 수 있다는 점을 생각해 따로 squash 기능을 사용해보진 않았습니다.
코드 스타일 맞추기
코드 스타일은 백명의 개발자가 있다면 백명이 다 다를것이라 생각됩니다. 만약 깃을 사용해 같은 프로젝트를 진행한다면 서로 제각각이라 협업하기 힘들것이 뻔하죠.
그런 문제를 해결하기 위한 방법으론 eslint, prettier를 적용하는 방법이 있습니다.
eslint는 코드 분석 툴로 불필요한 코드, 보안상 위험한 코드 등에 경고를 띄워줍니다.
prettier는 코드 포맷팅 툴로 팀원들의 코드 스타일을 통일 시켜줍니다.
물론 둘 다 규칙들을 커스텀할 수 있죠.
eslint, prettier 설정~!
저의 경우는 React 기반의 프로젝트를 진행하다 보니 creact-react-app을 예시로 들겠습니다.
터미널에 하단의 npm 명령어를 쳐서 의존성을 추가해주는데 이때 개발에만 필요한 부분이다 보니 devDependencies에 추가해줍니다. 이렇게 하면 빌드를 할때는 포함이 안되어 속도가 조금이나마 빨라지지않을까는 제 생각입니다
npm install eslint --save-dev
npm install prettier --save-dev
npm install eslint-config-prettier --save-dev설치 후에 해당 디렉토리 최상단에 각각의 설정파일을 만들어 두어야 합니다. 그 이유는 설정파일만 가지고있다면 팀원모두가 동일한 적용을 받기 때문이죠.
// .prettierrc.js
module.exports = {
printWidth: 100, // printWidth default 80 => 100 으로 변경
singleQuote: true, // "" => ''
arrowParens: 'avoid', // arrow function parameter가 하나일 경우 괄호 생략
tabWidth: 2,
};// .eslintrc
{
"extends": ["react-app", "eslint:recommended"],
"rules": {
"no-var": "error", // var 금지
"no-multiple-empty-lines": "error", // 여러 줄 공백 금지
"no-console": ["error", { "allow": ["warn", "error", "info"] }], // console.log() 금지
"eqeqeq": "error", // 일치 연산자 사용 필수
"dot-notation": "error", // 가능하다면 dot notation 사용
"no-unused-vars": "error" // 사용하지 않는 변수 금지
}
}Husky?
eslint + prettier를 도입하면 끝이 아닌데요. 설치를 했지만 작업자가 사용하지 않으면 효과가 없기 때문입니다. 매번 개인이 실행해서 확인하는 것도 강제성이 없기 때문이죠.
이 문제를 해결하고자 commit과 push 단계에서 자동으로 실행되게 git hook을 도입할 것입니다.
git hook은 설정이 까다롭고 모든 팀원들이 사전과정을 수행해야 보장받을 수 있습니다. 이를 좀더 쉽게 해결하고자 husky를 도입할 것 입니다.
Husky 설정
먼저 설치를 해야겠죠?
npm install husky --save-dev그 후에 처음 이것을 설치하는 사람만 다음 코드를 실행합니다.
npx husky install그리고 package.json의 스크립트에 다음 스크립트를 추가합니다.
// package.json
{
"scripts": {
"postinstall": "husky install",
"format": "prettier --cache --write .",
"lint": "eslint --cache .",
},
}마지막으로 저 같은 경우는 commit 전에는 prettier를 push 전에는 eslint를 실행할 것입니다. 따라서 등록해주는 명령어는 다음과 같습니다.
npx husky add .husky/pre-commit "npm run format"npx husky add .husky/pre-push "npm run lint"
참고사항
git hook에서 eslint 에러가 발생하면 script는 종료됩니다. 즉, 푸시가 안되겠죠.
따라서 eslint의 rule에서 warn으로 할 지 error로 할 지 잘 고려하는것이 좋습니다.
"no-console": ["warn", { "allow": ["warn", "error", "info"] }]
만약 eslint에서 warning 마저 허용하지 않으려면
스크립트의 lint 명령어에 --max-warings=0 옵션을 붙이면 됩니다.
// package.json
{
"scripts": {
"lint": "eslint --cache --max-warnings=0",
},
}마무리
위에 있는 내용을 잘 숙지한다면 팀프로젝트에 앞서서 기본적인 기본은 했다고 생각이 됩니다.
앞선 강의를 들으며 협업의 기본자세를 다시금 되새겼고, 이제의 목표는 하드 스킬은 당연하고 소프트 스킬도 능숙한 사람이 되고 싶어 졌습니다.
앞으로 좋은 팀원을 만나기 위해 저부터가 노력해야겠습니다.
