[항해 99 주특기 주차 15일차]

<회고록>

오늘은 태현님과 함께 블로그 프로젝트를 진행하면서 내가 협업을 할때 내가 쓰는 코드를 다른 사람이 읽기 쉬운지 내가 쓴 코드가 변화에 유동적으로 대응할 수 있는지를 체크하고 싶다는 마음에 팀원이 태현님과 함께 기술메니저님에 기술 블로그를 만들게 되었다. 그래서 오늘은 협업하면서 겪어던 문제들 그리고 이를 어떻게 해결했는지에 대해서 한번 적어볼려고 한다.

 

1. 네이밍 문제

내가 이번에 태현님이랑 협업을 하면서 느꼈던 첫번째 문제는 네이밍 문제였다. 둘이 쓰는 네이밍이 다르다 보니 서로의 네이밍을 이해하기가 굉장히 어려웠다. 예를 들어서 나는 ul 태그를 menu라고 지었는데 태현님의 경우는 list라고 지었다. 그래서 나는 이를 해결하기 위해서 components naming convension 을 찾아보았다. 그리고 이를 가지고 코드를 작성할 때 네이밍 규칙을 정했다. 이렇게 네이밍 규칙을 정하니 서로의 코드를 읽을 때 규칙이 생기고 이 규칙이 기준이 되어서 서로의 코드를 읽을때 굉장히 편해졌다. 그래서 나는 앞으로 폴더 구조, 파일 명 , 컴포넌트 네이밍을 통합해서 룰을 만들고 협업을 시작하는 것이 훨씬 좋다는 것을 깨달았다.

 

 

2. 컴포넌트 분리 문제

내가 이번에 태현님과 협업을 하면서 느꼈던 두번째 문제는 컴포넌트 분리 문제였다. 나는 컴포넌트를 잘개 쪼개서 각각의 컴포넌트의 추상화를 맞췄다. 하지만 이는 오히려 시선을 분산시키고 이로 인해서 결국엔 코드의 가독성이 떨어지는 문제가 발생했다. 그래서 결과적으로 나는 이런 문제를 해결하기 위해서 저번에 기술 매니저님의 말을 떠올렸다. 기술 매니저님이 저번에 컴포넌트를 나누는 기준을 2가지를 제시했었다. 1. 이 컴포넌트가 재사용성이 되는가? 2. 이 컴포넌트가 코드의 가독성을 해치는지 나는 이 2가지를 보았을 때 이번 컴포넌트 분리는 2가지 모두 해당되지 않았다. 즉 하나의 컴포넌트의 분리를 너무 어렵게 짜르는 것이 아닌 이 것을 짜르는 것에 대한 이유를 댈 수 있도록 작성하는 것 가장 정확한 컴포넌트 분리라고 생각한다.