개발자의 기본 협업

 

---

사전과제 피드백

원티드 프리온보딩 인턴쉽을 수강하기 위해 진행했던 사전과제의 피드백입니다.

과제의 분석

• 과제의 주제
  • Simple 인증 / 인가
  • Simple CRUD
• 과제에서 파악하고자 한 것 : 출제자의 의도
  • 기본적인 형태의 서비스를 만들 수 있는가?
  • 코드 스타일은 어떤가?
  • 프로젝트 구조를 어떻게 설계 했는가?
  • 과제를 수행하는 기본적인 태도
  • README.md 잘 작성되었는가?
  • Git활용은 잘 했는가?
• 코드 분석 ← 무조건 기업들이 보는것들
  • 코드의 가독성
  • 컴포넌트가 잘 분리되었는가?
    • 컴포넌트를 논리적인 단위로 분해 했는가?
      • 컴포넌트의 쓰임
      • 컴포넌트의 역할과 책임
  • 관심사가 잘 분리되엇는가?
    • 반복되는 코드들 : 추상화하고 분리했는가?
  • 프로젝트의 아키텍쳐는 어떻게 설계 되었는가?

과제의 목표 ?

과제의 목표는 채용당하는것.

기업에서 과제를 내주는것은 채용을 위한것이다.

과제를 내주는 것은 기업입장에서 투자를 많이 하는것.

→ 실무진들이 함께할 동료를 뽑는것이다.

채용의 실패는 내가 안좋은 사람을 뽑는것이다.

→ 따라서 안좋은 지원자를 최대한 걸러내기 위한 태도를 취한다.

→ 기본적으로 지원자를 평가하는데 있어서 방어적인 태도를 기본적으로 가지게 된다.

평가하는 사람이 내 과제를 계속해서 보고싶게 만들어야 한다.

→ 애초에 시작부터 장점을 보게 만들어야 평가하는 사람이 긍정적인 프레임에 머물게 된다 → README.md를 더 더 더 열심히 써야 겟다.

→ 평가자가 내 과제에 더 오래 머물고, 더 오래 보고, 나아가서 이 과제를 수행한 나라는 사람에 대해서 더 알아보고 싶게 만들어야 한다.

• 애초에 이력서에는 나의 관심사를 넣을 필요가 없네..

사실 개발자의 코드는 항상 읽는 사람에 초점을 맞춰서 작성해야 한다.

읽기 싫은 코드

• 제대로 접근이 되지 않는 링크들
• 작성되지 않는 부실한 내용의 README.md
• 기능이 돌아가는지 확인하기 힘든 과제
• 허가되지 않은 라이브러리의 사용
• 규칙성이 없는 코드의 포멧팅 및 변수명
• 관리되지 않은 GIT(commit histroy. branch)

---

개발자의 기본기

개발자로서 갖춰야할 역량은 무엇이 있을까요?

• 하드 스킬
• 소프트 스킬

개발자에게 협업과 커뮤니케이션이 강조되는 이유는 개발자 혼자서는 하나의 프로덕트를 만들 수 없기 때문 → 개발자 뿐만 아니라 수많은 직군들과 협업을 통해서만 만들어 낼 수 있음.

특히 프론트엔드 개발자는 업무 특성 상 흔히 기획자, 마케팅, 디자이너, FE 개발자, BE 개발자로 구성되어 있는 제품팀에서 모든 직군들과 가장 많이 소통을 해야하는 포지션이다.

타 직군 사람들에게는 생소한 부분이 많다. 따라서 이런 생소한 영역을 청자를 고려해서 알아들을 수 있게 쉽게 풀어서 설명할 수 있는 능력을 갖추는것이 굉장히 중요합니다.

소통은 말로하는 소통, 문서로 하는 소통 → 구두로 하는 소통은 ‘상대방을 이해시키기 위함’임을 명심해야 합니다.

개발자가 주로 작성하는 문서는 commit, pr, 그리고 코드입니다. 이러한 문서를 통해서 개발자들은 서로 의도를 표현하고, 피드백을 주고받고, 팀의 능률을 올리기 위해 노력합니다. → 이러한 문서들의 중요성을 인식하고, 이를 잘 작성하고자 노력하는 것은 굉장히 중요한 일이다.

Git & Github

• 문서와 협업툴의 역할로 굳혀지고 있는 중이다…
• 깃은 가장 기본적인 문서 작성이다. 왜 이렇게 짯는지 언제 짰는지.. → commit message와 그 때 바꾼 코드를 같이 볼 수 있거 누가 언제 작성했는지 알 수 있다.
• 개발자는 팀을 나눠서 한다. 팀 내에서 일관적인 커밋메시지를 작성해야 한다.

history 관리 밎 브랜치 관리 전략

커밋들이 늘어나면 늘어날수롯 점점 맥락을 파악하기가 힘들어질 것입니다. → 이를 히스토리 관리로 잘 관리 해야한다.

• 그렇다면 유의미한 커밋만 작성해야 할까요??
  • 작업중에는 원하는 만큼 커밋을 남기되, 최종적으로 브랜치의 작업이 완료 되고 pr을 통해서 master에 머지 전 시점에 여러 커밋을 하나로 합칠 수 있습니다.
  • ⇒ sqush를 통해 여러 커밋틀 하나로 합칠 수 있습니다. (rebase, interactive )

팀 내에서 히스토리를 어떻게 깔끔하게 관리할 수 있을 지 고민하기

ESLint 와 prettier, Git Hook을 이용해 팀의 능률 올리기

• 컴퓨터에게 코딩 스타일을 맡기는
• Lintting 기능은 ESLint, Code Formatting은 Prettier에 일임하는 방식으로 사용
• 자동화 될 수 없는 컨벤션은 최소화 하는것이 좋고, 필요한 경우에는 반드시 문서화를 시키고, 의견을 조율해야한다.
• 한번 해두면 추후에 적용하기도 쉽고, 무엇보다 초기에 세팅해둔 것이 지속적인 개발 생산성 향상에 도움을 줍니다.
• 만약 캐싱을 했다면, .gitignore 파일에 잘 넣어 주자.

⚠️ npm 패키지.json의 개발 환경을 잘 구분하는게 중요함

—save-dev → 개발 시에만 사용하고, 프로젝트 구동환경에서는 필요가 없다.

❗package.json 의 scripts 부분을 이용해 자동화를 하면 개발자의 능률을 올릴 수 있을 것이다.

Husky

eslint 끄면 어떡할건데??? 니가 뭘 할 수 있는데?? 난 팀원들 의견 개 무시할건데??? 끄고함 ㅅㄱ

• 아무리 패키지를 설치하고, 룰을 설정해도 작업자가 사용을 안하면 효과가 없음
• 사용자가 설정을 안해도 자동으로 계속 돌아갈 수 있도록 해야한다.

문제 해결 방안

• 자동화를 통해서 신경쓰지 않아도, 자동으로 적용이 되게 하고 특정 상황에서 강제로 적용이 되게 하자.
• commit 된 코드는 무조건 포메팅으 완료, push된 코드는 무조건 eslint가 pass된 상황에서 push할 수 있도록 자동화를 구축해야

git hook 도입을 해보자

• 깃 훅 도입 → git에서 특정 이벤트 발생하기 전 후로 특정 hook 동작을 실행할 수 있게 하는것
• 본인 저장소에 수동적으로 설정해야 보장가능
• 그 과정이 귀찮

Husky를 통한 Git Hook 적용

(husky의 장점 알아보기)

1. npm install husky —save-dev
2. 설정하는 사람만 설정을 완료하면, 다들 자동으로 적용이 된다.

lint-staged → 랑 같이 사용한다.

git add를 한 파일 (스테이징된 파일)에 대해서만 린트를 돌려주고 다시 add하고 커밋해준다.

😒 husky를 설정해 두면 vscode처럼 ide 커밋으로 푸쉬할 때도 막아주는건가?

❔ 왜 위와 같은 짓을 계속 하는가?? 우리가 함께 으쌰으쌰 하기 위해서 이다.

우리가 함께 일할 건데 이 약속을 미리 정해서 우리의 개발 생산성을 높이고 협업 과정을 좀 더 원할하게 하기 위함이다.