공유, 공유, 공유

스타트업에서 팀으로 일한다는 건, 끊임없이 소통해야 한다는 뜻이다.

아이디어를 떠올리고, 디벨롭하고, 디자인과 개발을 해나가는 일련의 과정 속에서,

멈춤 없이 서로의 생각과 진행 상황을 공유해야한다는 뜻이다.

 

반대로 말하자면, 서로의 생각과 진행 상황이 공유되지 않으면...

굉장히 답답하다. 나의 일을 하는데 지장이 생긴다.

 

프론트 개발자로서 특히 필요한 소통은 → 다른 프론트엔드 개발자 / 디자이너 가 있겠다.

 

1.  다른 프론트엔드 개발자

git hub를 적극 활용하는 수밖에 없다.

현재 팀에서는 issue와 pull request를 통해

잔여 task를 파악하고, 작성한 코드를 서로 리뷰하는 형태로 개발을 진행하고 있다.

 

여기서 직접적으로 각자의 결과물 공유는 pull request를 통해 이뤄지는데...

해당 pull request의 크기가 너무 크거나, 작을 경우 전체적인 맥락 파악이 어려운 문제가 발생한다.

(응집도가 떨어지게 된다)

→ 따라서 특정 맥락 내에서 코드를 작성하고, 이를 공유하는 습관을 길러야 한다. 의식적으로 노력해야 한다.

 

2.  디자이너

QA가 굉장히 부담스러울 때가 있었다. (지금도 마찬가지일 지도? 하하)

왜? 인지 곰곰이 생각해 보니... 

당최 어떤 수정 사항이 날아올지 모른다는 불안감! 때문이었다.

 

QA시 발생하는 수정 사항은 크게 두 가지였다 → 기능적인 요소와 디자인적인 요소

테스트하는 팀원들이 위 두 맥락의 수정 사항을 중구난방으로 얘기하니, 별 것 아닌 사이즈의 task도 부담스럽게 다가왔다.

 

그렇다면... 이를 어떻게 개선할 수 있을까?

→ 두 맥락의 테스트를 따로 진행하면 되지 않을까???

 

지난 스프린트 때 진행했던 채팅 과 같은 경우

기능적 요소 : 앱 내 채팅 목록이 뜨는지, 각 채팅방에 접근이 가능한지, 메시지가 송수신되는지, 읽음 상태가 변경되는지 등

디자인적 요소 : 채팅 목록 아이템, 말풍선, input form 등

으로 구분할 수 있을 테다.

 

그리고 위 두 요소는... 많은 부분이 서로 간에 독립적이다.

→ 이를 꼭 한꺼번에 테스트할 이유가 없다.

 

https://storybook.js.org

Storybook: Frontend workshop for UI development

UI 컴포넌트는, 해당 컴포넌트가 작성되었을 때 테스트를 하면 그만이니!

 

이를 위해 storybook과 같은 툴을 도입하는 것도 하나의 방법이 될 수 있다.

하지만 이를 근본적으로 가능하게 만들기 위해서는...

(수백 번은 적은 것 같지만) 철저한 관심사 분리가 필요할 테다.

 

UI 컴포넌트는, UI 컴포넌트의 역할을 해야 한다.

해당 컴포넌트 내부에서 데이터를 조회하거나 이를 변경하는 등의 로직이 뒤섞이는 순간...

이를 공유하기는 점점 어려워진다 → 해당 로직과 관련된 사항이 완료되어야 공유가 가능할 테니!