마지막 미션은 6주간의 그룹프로젝트였다. 4명이 모여서 원하는 주제를 선정하였고, 우리 팀은 실시간으로 마인드맵을 만들면서 프로젝트를 디벨롭시키고 애자일하게 관리할 수 있도록 백로그, 차트, 칸반보드, 캘린더를 제공하는 협업툴을 기획하였다.
6주간 여러가지 일들이 있었고, 배운 점도 많았는데, 떠오르는 것들을 간단하게 키워드를 통해서 남기려고 한다.
🧙♂️ 설계에 대해
우리 팀은 실시간으로 마인드맵을 주고 받으며, 과거 변경 이력을 추적할 수 있는 데이터 구조를 고민했다. 이를 위해 스냅샷, 변경된 노드 저장, 변경된 이력 저장 등의 방법들을 후보로 두고 DB의 효율성, 소켓 통신에서의 효율성, 구현 난이도 등에 고민하고 정리하였다. (정리한 글) 스토리를 상상해서 해당 케이스는 어떻게 처리할 지 그려가며 설계를 하였는데, 트레이드 오프 관계에서 치열하게 토의가 엄청 길어지기도 하였다. 내가 고집을 피운 것 같아 팀원들에게 미안한 마음도 들었지만, 고민을 많이 한 만큼 치밀한 설계가 나온 것 같다.
내가 어느 기업에 가서 자랑할 만한 팀 문화를 여쭤봤는데, 시니어가 쥬니어의 설계 단계에 함께 해 꽃길만 걸을 수 있도록 해준다고 하셨다. 꽃길이란 표현이 공감이 갔다. 설계가 튼튼하면, 구현은 정말 쉬웠다.
🧙♂️ 협업에 대해
팀원들과 협업을 느꼈던 어려운점은 다음과 같다.
-
분업이 미숙했다. 우리는 마인드 맵 기능이 워낙 큰 부분이라, 태스크를 쪼개기가 어려웠고, 어떤 부분이 구현이 안되면 구현이 힘들어서 우리끼리 데드락(?)이 걸리기도 하였다. 현업에서의 분업을 여쭤보니, 보통 페이지별로 구현을 한다고 하셨는데, 이렇게 큰 기능은 나누기 어려울만하다 하셨다. 최대한 다른 일들을 찾아서 하면서, 팀원을 기다리는 쪽으로 했다.
-
팀원과 커뮤니케이션에서, 내가 납득이 될 때까지 집요하게 물고 늘어지는 경향이 있었다. 한 가지 느낀점은 결국 엔지어링은 트레이드 오프고 정답이 없는데 내가 너무 고집을 부렸다는 생각이 들었다.
-
머릿속에 있는 것을 말로 설명하는 것을 좀 더 연습해야겠다는 생각이 들었다. 예를 들면, "그거는 00할 때 안돼요"라는 문장에서 "그거는, 어떤 상황에서, 어떤 행동을 하려고 할 때, 어떻게 작동해서 안돼요" 라고 말하는 연습을 해야겠다. 내가 추상적으로 말하는 데도 알아들어주는 팀원들에게 고맙기도 하고, 말하기 전에 한 번더 정리를 하고 말하는 습관을 들여야겠다는 생각이 들었다.
🧙♂️ 코드리뷰에 대해
선진 개발 문화를 실천하기 위해, 팀원의 코드리뷰가 없이는 merge시킬 수 없도록 해두었다. 마지막 배포 때가 다가와서는 댓글없이 approve시키는 사태(?)가 일어나긴 하였지만 좋은 리뷰에 대해 고민을 했다.
느꼈던 좋은 리뷰거리는 다음과 같다.
- 요구사항 구현 (문제를 해결하는가, 엣지 케이스는 없는가)
- 변수명, 함수명 (다른 개발자가 이해할 수 있는가)
- 컨벤션 (우리가 세운 규칙에 맞는가)
- 중복코드 (어 이 부분 가져다 쓰면 되는데...)
코드 리뷰를 하면서 느낀 점은
-
결국 협업을 위한 과정이다. remote에 이 코드가 올라가게 될 텐데, 이 코드를 나중에 누군가가 보고 수정할 수 있겠어? 라는 기준에서 바라보는게 도움이 됐다.
-
남의 코드를 읽어두는 것은 중요하다. 자세히 들여다보면 이런식으로 짤 수도 있구나 알 수 있고, 나중에 가져다가 혹은 수정해서 활용할 수도 있다. 적어도 어떤 커밋이었는지 정도는 기억하는게 필요한 것 같다.
-
팀원 규모에 따른 비효율성은 존재할 것 같다. 4명이서 리뷰하는데도 (프로젝트도 초반이라 코드량이 많다고 쳐도) 꽤나 시간이 필요했다. 만약 100명이서 한 프로젝트를 만든다? 하루종일 리뷰만 하고 있을지도 모른다. MSA가 효과적인 이유가 여기에도 있지 않을까? 적은 사람이 최적화된 코드를 짤 수 있으니깐 말이다.
🧙♂️ 테스트에 대해
마지막 주차는 리팩토링과 테스트코드를 위한 주차로 사용을 했다.
테스트의 중요성에 대해 배웠는데, 우리는 아토믹 패턴을 적용하면서 컴포넌트의 재사용성을 높이고자 하였고, 그러다보니 복잡성이 높아지면서 사이드 이펙트가 생겨나고, 수정이 어려워졌다. 내 코드가 다른 사람의 수정에 영향을 받으면서, 내가 다시 수정을 할 일이 생기고... 테스트를 짜놨더라면 코드를 보호할 수 있었겠다고 느꼈다.
테스트코드를 작성하려고보니, 내 코드가 테스터블하지 않은 부분을 발견했다.
-
소켓 통신의 부하테스트를 하고 싶었는데, 우리는 type,data로 두 개의 args로 소켓에 emit하고 있었는데, 라이브러리에서는 하나의 arg만을 지원하는 것을 알게 되었다. 미리 알았더라면 이렇게 짜지는 않았을텐데, 지금은 너무 많은 코드를 고쳐야했다.
-
Recoil의 테스트가 쉽지 않았다. 상태관리 라이브러리를 선정하면서 공식문서를 보면서, "어 테스트는 snapshot으로 하면되겠네" 하고 넘어갔었다. 막상 테스트를 하려고보니 Recoil의 테스트 부분이 아직 빈약하다는 것을 깨달았다. 일단 snapshot이 unstable 단계였고, 그래서 그런지 자료가 부족했다. 훅을 통해 상태변화가 반영이 되지 않아 버튼을 클릭했을시 상태변화를 추적하는게 아니라, 버튼을 클릭하면 jest.fn이 호출되는가 + 리코일상태를 변경시키면 예상되는 값이 들어있는가로 1차원적인 테스트코드 두 개로 나눌 수 밖에 없었다.
-
컴포넌트가 테스터블 하지 않았다. 우리는 css-in-js를 사용했는데, class name을 짖지 않아도된다는 장점이 사용 이유 중 하나였다. 하지만, 막상 jest로 단위 테스트를 하려고 하니 class name없이 Dom을 다루기가 힘들었다. 또한 props가 많아지는 것이 보기 싫어서 onClick 핸들러들을 내부에 선언했는데, 이 때문에 jest.fn을 주입해서 테스트하기가 힘들어졌다. (하나만 알고 둘은 몰랐다라고 할 수 있겠다...)
결국, 테스트 코드와 리펙토링에 대해서는 더 공부가 필요하다고 느껴졌다. TDD에 대해 더 공부해보고 연습해볼 필요성을 느꼈다.
🧙♂️ 나에 대한 칭찬
-
팀원들 편하게 개발에 집중할 수 있는 CI/CD 환경을 구축했다. 자동 배포, 테스트와 lint 자동화 환경을 구현해 퀄리티를 보호하고, 팀원들이 개발에 집중할 수 있는 환경을 만들었다. 관련 글
-
기반이 되는 컴포넌트와 커스텀훅을 만들어 팀원들이 재사용할 수 있도록 했다. 글로벌 모달을 구현해 확인 모달창, 입력 모달창 등 쉽게 모달창을 생성하게 하였고, Toast를 구현해 쉽게 알림 메시지와 에러 메시지를 띄울 수 있게 했다. 누군가 내 코드를 재사용하는 즐거움을 느꼈다.
-
프로파일링을 통해 최적화를 진행했다. 불필요한 렌더링을 막기위해 컴포넌트를 분리해 관심사를 분리하고, transform을 사용해 리플로우를 막았다. 스스로 리액트에 대해 꽤나 강해졌음을 느꼈다.
마치며
여러모로 느낀게 많은 프로젝트였다. 모자란 점은 끄저끄적 계속 추가해보면 재밌을 것 같다. 특히, 팀원들과 함께 하면서 현업에서의 고민을 간접체험 해 볼 수 있었다. 개발자가 혼자가 아닌 이상 결국 팀워크이고, 어떻게 협업할지에 대한 고민을 계속 할 수 밖에 없을 것 같다. 프로젝트를 통해 강해졌지만 아직 부족한게 많다는 것을 더 느낀다...🐥
