남들 따라하는 것이 아닌, 우리만의 코드리뷰 문화를 이야기해보고 결정하여, 정착시켰으면 합니다.
1-2. 코드리뷰를 하면 뭐가 좋을까?
자신은 알고 있는 부분을 타인에게 설명하면서 다시 생각을 정립할 수 있습니다. (자신 실력 상승)
타인에게 설명하기 위해 작성한 코드를 한번 더 보게 되어 스스로 확인하게 됩니다. (셀프 피드백)
코드를 짤 때 최대한 이해하기 쉽게 짜게 된다. (가독성 좋고, 좋은 코드 작성 가능성 상승)
자신이 개발한 부분만 아는 것이 아니라, 동료들의 부분을 좀 더 알게 되어 전반적인 서비스 로직의 이해도가 올라간다. (서비스 이해도 향상)
Code Convention(패턴)을 확실하게 통일할 수 있다. (통일성)
자신이 놓친 실수를 피드백하고 도와줄 수 있다. ( print문 실수, 오타 등 실수캐치 )
동료의 코드를 보면서 새로운 스타일이나 깨달음을 얻을 수 있습니다. (발전)
즉, 코드리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 한다.
2. 코드 리뷰 매뉴얼
2-1. 기본 규칙
서로의 잘못이나 오류를 지적하려는 의도가 아니라 피드백을 해주는 것이다. ( 공격적인 말투는 절대 X )
코드엔 정답이 없기때문에, 무조건 누가 맞는게 아니라, 함께 발전시키는 것이다.
질문을 하거나 대답을 할 때는 상대방이 상황을 전혀 모르다고 가정하고 충분한 문맥을 전달해야 한다.
당장 운영에 문제가 있는 hotfix건과 주석 제거와 같이 로직에 큰 변화가 없는 건은 스킵한다.
작은 작업 및 기능 단위로 PR(Pull Request)를 올리고, Merge 전에 코드리뷰를 진행한다.
2-2. 코드리뷰 규칙 ⭐️⭐️
PR남기는 사람
PR 본문은 PR 템플릿(Pull Request Template)에 따라 일관된 형태로 남긴다.
PR에는 최소 2명의 리뷰 담당자를 지정한다.
리뷰어
리뷰 담당자는 가벼운 마음으로 아래 역할을 수행한다.
오타 찾기 ( print문, 오타, convention오류 등 )
모르는 것 질문하기 ( 변수명, 비즈니스 로직 등 )
질문받은 사람은 이를 설명하면서 다시 복기할 수 있고 질문한 사람은 답변을 보고 로직에 관한 지식을 얻는 게 목적
새로운 대안 제시하기 ( 이건 A 목적인 건가요? A 목적이 맞는다면 이렇게 해보면 어떨까요?)
되도록 읽는 사람이 한 번에 정보를 확인할 수 있도록 한다. ( 가독성 생각하기 )
급한 우선순위 작업이 아니라면, PR을 틈틈히 Review하자 ( 당일 내로 처리하는 것 추천 )
리뷰할 것이 없으면, 칭찬남기기. → 모든 리뷰는 댓글에 하면된다.
만약 너무 바쁜 상황이라, Reivew를 하지 못할 상황이라면 다른 사람을 리뷰어로 지정해달라고 말하자.
2-3 Pull Request Template
제목
PR의 제목에는 가장 뒤에 [D-??] (??에 숫자 넣기)
언제까지 리뷰를 요청하는지 적기. (우선순위 파악 목적)
만약 오늘까지 리뷰를 해줬으면 하면, D-0이렇게 추가
Ex) D-1 이벤트 페이지 구현완료
본문
### 작업 분류
- [ ] 버그 수정
- [ ] 신규 기능
- [ ] 기존 기능 수정
### 기능 기획
<!--
왜 이 기능을 추가했는지 간단하게 적기
ex) 고양이가 울지 않으니 고양이 같지 않아서, 고양이 야옹소리 기능 추가
-->
### 작업 개요 ( 대분류 )
<!--
ex) 고양이가 야옹 소리를 내도록 수정
-->
### 작업 상세 내용 ( 상세 분류 )
<!--
ex)
1. 네 발 짐승 클래스에 `크앙` 함수 추가
2. 고양이 클래스에서 `크앙` 함수에 `미야아옹.wav` 재생시킴
-->
### 테스트 내역
<!--
ex)
1. 페이징이 잘 처리되는지 확인
2. 특정한 값을 넣었을때 제대로 처리하는지 확인
-->
아래 링크를 참고하면 PR Template 생성 가능 (Repository 관리자만 가능 - Bitbucket 관련)
리뷰 내용 가장 앞에 Pn을 입력하면 좋을 것 같습니다. ( 코멘트를 강조하는 수준 표현 )
P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
P2: 웬만하면 반영해 주세요 (Comment)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
P3: 그냥 사소한 의견입니다 (Approve)
작성자는 P3에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
3. 마무리
더 좋은 코드와 서비스를 만들기 위해서는 좋은 개발문화가 있어야 합니다.
현실에 타협하지 않고 더 좋은 서비스를 만들기 위해 코드리뷰 문화가 더 잘 정착하면 좋다.
억지로 하는 것은 문화가 아닙니다. 우리가 왜 하는지 알고, 함께 자발적으로 만들어나가는 것이 문화라고 생각한다.
코드리뷰 문화도 정답이 있는 것이 아니라 팀의 특성에 따라 잘맞는 방법이 다르다.
제가 쓴 것이 정답이 아닌, 함께 이야기해보고 자신의 팀에 가장 잘 맞는 코드리뷰 문화를 만들면 좋겠습니다.
이번에는 주로 작은 서비스에서 자주 쓰이는 EventBus에 대해 알아볼 것이다. 조금 규모가 커지면, 보통 Vuex를 사용하는 경향이 있다. 그래도 알아두면 나쁠것은 없으니 알아보자.
부모/자식 컴포넌트 사이에서 호출하기 위한 설정-> 부모컴포넌트와 자식컴포넌트 사이에는 특별한 호출방식이 있다.
모든 컴포넌트에 적용할 데이터/메소드 설정 -> 전역변수로 생각하면 편하다.
전혀 관계없는 컴포넌트 사이에서 호출하기 위한 설정-> 아무관계도 아니지만, 전역으로 할 필요는 없는 경우
3. 전혀 관계없는 컴포넌트 간의 호출 - EventBus
일반적으로 메소드, 변수를 정의할 때 한 오브젝트나 컴포넌트 단위로 묶어서 사용되기 때문에 이벤트를 사용할 필요가 없이 현재 위치에 포함된 메소드/변수를 호출하여 사용할 수 있습니다. 하지만 각각 분리되어 있는 개체에 전송하거나 알려줘야한다면 어떻게 해야할까요?
이럴때 공통으로 데이터들을 주고 받을 수 있는 공간을 만들고, 이를 통해서 서로 규격에 맞춰 데이터들을 주고 받으면 될 것 입니다. 이벤트를 등록하고 받을 준비가 끝났다면 언제 어디서든지 데이터들을 주고 받고, 각 이벤트요청 상황에 따라 원하는 메소드들을 수행할 수 있게 만든 것이 EventBus입니다. 쉽게 말해 컴포넌트간 메소드들을 서로 호출하게 해주는 것입니다. 아무 관계가 없는 컴포넌트 사이에서도 가능합니다.
vue.js에서 이벤트를 쉽게 다루기 위해 EventBus라는 개념을 이용할 수 있으며, 누구나 쉽게 사용할 수 있습니다.
// 이벤트버스 생성
var EventBus = new Vue()
// 이벤트 발행
EventBus.$emit('message', 'hello world');
// 이벤트 구독
EventBus.$on('message', function(text) {
console.log(text);
});
자, 이렇게 하여 vue.js에서 이벤트를 쉽게 활용할 수 있습니다. 위와 같이 구현해놓는다면 컴포넌트, Vueapp이 전혀 다르더라도 서로 쉽게 호출할 수 있습니다.
이렇게 Vue에서 데이터/메소드를 호출/교환하는 방법에 대해 알아봤습니다. 저도 공부를 하며 정리한 것이라 틀린내용이 있을 수 있습니다. 또한 제가 모르는 것들이 더 많을 수도 있습니다. 그럴땐 꼭 피드백 부탁드립니다. 감사합니다.