원티드 프론트엔드 인턴쉽 10기 - 1주차 - (3)

 

두 번째 회의 때도 역시 이전포스팅 에서도 말했지만 새로운 회의 템플릿을 적용하고 회의를 시작했다.

 

하지만 생각보다 논의사항에 팀원들이 안건을 적어두지 않아서 길을 살짝 헤매었던 거 같다.

 

기존에 논의사항을 적어두면 더 효율적인 회의를 진행할 수 있을 거 같아서 많이많이 팀원들에게 강조해야겠다..!

 

 

 

 

 

그리고 이번에 새로 도입한 Request For Comments는 비동기적으로 팀원들과 소통하고 싶어서 만든 탬플릿이다.

 

회의 템플릿중 공유사항 부분에서 각 팀원들에게 현재 진행상황을 브리핑하고 나서 일단 넘어가지만, 그 부분에 대해서 따로 팀원들이 코드를 살펴본 뒤 더 괜찮은 아이디어가 뒤늦게 떠오를 수 있기 때문에 만든 탬플릿인데, 이 탬플릿에 대한 각 섹션을 설명을 하면,

 

---

Request For Comments

🙋‍♂️Suggest

한 팀원이 현재 코드에 대한 부분의 개선을 위해서 모든 팀원들에게 제안을 하는 파트다.

 

예를 들어, 

 

투두에서 공백문자열을 판단하는 함수가 컴포넌트 내에서 선언이 되었는데 유틸함수로 빼는 건 어떤가요?

 

이렇게 이 제안에 대한 운을 띄운다.

 

그 이후에

❗ When to follow this process

 

현재 이 코드는 이러한 과정으로 진행이 된다. 그렇게 되면 이렇게 될 것이다.

 

라는 잠재적인 문제점을 표현한다. 예를 들어,

 

공백문자열을 판단하는 함수가 또 필요할 때 해당 컴포넌트에서 또 선언하거나
투두에서 export를 해야 하는데 코드 결합도가 낮아서 가독성이 떨어질 우려가 있습니다.

As-is

기존 코드에 대한 설명을 하고,

투두에서 공백문자열을 판단하는 함수를 투두에서 선언함

To-be

바뀔 코드에 대한 설명을 한다.

공백문자열을 판단하는 함수를 유틸함수로 분리해서 사용

👏 What to expect

 

그리고 이러한 변화가 어떠한 기대가 있는지 적으면 된다.

공백문자열을 판단하는 함수를 유틸함수로 분리해서 사용하면 코드 결합도도 높아지고 기능이 확장됐을 때 재사용하기 좋아질 거 같습니다.

Approval

노션에는 투표, 확인 기능이 없기 때문에 임시로 [ ] 체크박스 형식으로 만들어서 승인했다라는 제스처를 남기면 된다..!

• [x] 이** → 좋은 거 같아요!
• [ ] 홍길동 -> 저는 기존 코드가 이러이러해서 더 나은 것 같습니다.

 

 

그리고 나서 RFC를 올린 사람이 다수의 승인을 받고 결정이 된다면 코드 수정을 하면 된다.

---

 

 

이런식으로 탬플릿을 만들어 왔는데 생각보다 많은 팀원분들이 바로 참여해주셔 가지고 뿌듯했다.

 

 

 

개발자들의 코딩 역량도 중요하지만 팀으로써 어떻게 잘 협업할지 협업에 대한 고민또한 코딩역량 못지않게 중요한 것 같다.