스타트업 절망편3
협업의 절망편... 이너피스...
협업의 기회가 생겨서... 잠깐이나마 행복했다.....^^
이내 내가 꿈꾸는 협업은 마치 닿지 않는 유토피아였음을 머지않아 깨달았지만...
충돌 없이 굉장히 깔끔한 형상관리
가독성 좋게 짜인 코드
더할 나위 없이 완벽한 문서
로 이루어진 협업은 차라리 내가 분신술을 배워 두 사람이 되는 것이 더 빠를 정도였다.
"난 아직 누군가를 관리할 깜냥이 부족한가 보다..."하고 울기도 울었다.
나도 친절하고 상냥한 사수이고 싶었다.
그러나 내가 부사수에게 이해하지 못하는 부분은 명확했다.
가령 이렇다.
#1.
나는 프로젝트의 본격적인 개발에 들어가기 전 기능정의서와 이슈트래커를 만들어놓는다.
어차피 혼자 볼 문서이기 때문에 기능정의서와 WBS가 합쳐진 혼종에 가깝지만 덕분에 내가 개발해야 할 기능과 일정을 한 번에 산출할 수 있다.
"00님, 이제 제가 이어서 개발을 진행해야 할 것 같아서 이슈트래커 문서 있는데 기존 문서 참고하여 작성 부탁드려요"라고 말했다.
그리고 받은 내용 중의 일부는 아래와 같았다.
(구체적 기능명) 관련 수정
(구체적인 컴포넌트 이름)의 바텀시트 추가 작업 필요
메신저로 준다고?라는 꼰대 같은 생각은 차치하고
무엇을 어떻게 변경하라는 건지, 뭐가 문제인건지를 전혀 알 수 없어서 당황스러웠다.
#2.
문서작성이야 사실 개발의 영역도 아니고 학교에서 알려주는 것도 아니니 이해할 수 있는 영역이다.
하지만 무지성으로 작성한 코드는 많은 생각을 하게 하였다.
무슨 의도지?
왜....?
항상 이렇게 작성했나....??
물론 문제는 없지만..... 곧 생길 것 같은데..?
React나 Javascript나 아무래도 개발자의 자유도가 높은 라이브러리/언어이다.
그렇다 보니 개발자의 실력이나 센스에 많이 좌지우지되는 것 같다.
- 왜 리턴되는 타입이 다른가?
: 물론 Javascrip는 타입이 달라도 변수에 할당할 수 있기에 문법 상 틀린 것은 아니다.
하지만 Typecript를 더 많은 회사에서, 더 많은 개발자들이 사용하는 이유를 생각해 본다면....
무엇이 문제인지 알 수 있을 것이다.
- 왜 API 문서에 없는 응답코드를 분기처리 했는가?
: http의 상태코드와 서버에서 데이터로 내려주는 상태코드를 구분하지 못했던 것 같다.
당연히 걸리지 않을 조건문이 왜 있던 걸까...
- 왜 함수에 파라미터를 받고서 사용하지 않는가?
- css객체 리턴은 왜 함수로 작성한 거지?
: 물어보니 이전 회사에서는 항상 그렇게 사용했다고 한다. 이것도 굳이 따지자면 틀린 건 아니기 때문에
정말 틀렸던 부분만 리뷰해 주었다.
- (새롭게 발견된) 컴포넌트 임의로 복붙하기
: 내가 만든 컴포넌트를 이름도, 내용도 변경하지 않고 그대로 복사해서 사용하고 있었다.
여기저기서 혼용해서 사용중이었고, 저렇게 복붙한 컴포넌트의 종류는 다양했다.
심지어 내가 담당하고 있는 페이지(디렉토리)에 만들어놓았기 때문에
나는 한치의 의심도 없이 내 것인 줄 알고 사용했는데, 수정사항이 반영이 안되는 것이었다.
#3.
더 어지러웠던 순간은 그 이후였다.
"코드리뷰 해줬는데 못 적어서 기억이 안 나요 다시 해주세요"라는 메신저를 받고서는 정말 울 뻔했다.
물론 더 어질어질했던 순간도, 자잘하게 귀찮은 순간도 많았다.
상용 브랜치에 바로 merge를 한다거나, 심지어 틀린 레포지토리에...
요구사항을 한 번에 이해하지 못한다거나,
업무의 우선순위를 파악하지 못한다거나...
가장 큰 문제는 사실 회사 그 자체에 있다.
나는 나대로 바쁜 상황에서 신입에게 교육을 시킬 여유 따윈 없었다.
https://brunch.co.kr/@5c684f75c47e4a9/39
이 글을 보면 알겠지만 정말 교육시킬 시간이 없었다.
그게 못내 안쓰러우면서도 또 귀찮았다.
