임시 보관함에 잠들어있던 회고록 먼지 털기
팀원의 이탈, 클린 코딩
기능 구현을 완료하고 백엔드 팀원끼리 전체 테스트를 진행했다.
당연히 여러 수정 사항이 발생했고 수정 하는 과정에서 다른 팀원의 코드를 보고 도와주어야 할 일이 생겼다. 그런데 A 팀원이 심한 하드 코딩을 해서 알아보기가 정말정말.. 힘들었다. 정말 도와주고 싶었는데 어디서 문제가 발생했는지 찾기도 힘들었다.
그래서 A팀원에게 일단 메서드를 최대한 분리해보자는 부탁을 드렸다. 그 이후에 같이 다시 살펴보자고 말씀드렸고, 나는 내가 맡은 도메인의 수정 사항을 보완하며 기다리고 있었다.
그런데 그 분이 .... 갑자기 프로젝트 막바지에 하차를.....하셨다................
팀 분위기가 좋았고, 서로 으쌰으쌰 하며 열심히 했던 터라 허무함이 없었다고 할 수는 없었다.
그래서 어떻게 해결했는가?
일단 남은 B팀원과 상황을 공유했다.
이제 백엔드가 두 명 남은 상황이라 남은 분이 힘들어 하시진 않을까 걱정이 되었다.
그래서 긍정적인 면을 계속 말씀드렸다.
“다른 분이 작성한 코드를 수정해보는 것도 우리한테 정말 좋은 경험이 될 거다.
어쩌면 우리는 프로젝트 기간 내에 유지, 보수도 경험해 보는 거다!! 힘들겠지만 힘내자!! 할 수 있다!! 잘 헤쳐나가봅시다”
했더니 그 분도 다행히 든든해하셨다.
그리고 남겨진 작업을 분배해서 수정을 시작했다.
먼저, A 팀원이 작성해두셨던 코드를 분석했다.
컨트롤러부터 시작해서 매퍼를 수정하고, 서비스 단에 하드코딩 된 부분을 분해하기 시작했다.
기억에 남았던 부분은 A 팀원이 ReservationService에서 StoreRepository를 주입하여 사용했던 것에서, 역할을 분리하여 StoreRepository가 아니라 StoreService를 DI해주는 것으로 수정했던 점이다.
ReservationService는 예약에 관련된 기능만 담당하도록 역할을 분리했고, 예외처리가 부족했던 부분을 추가하며 처음부터 쌓아갔다.
그리고
프로젝트가 빌드되면 될 수록, 커지면 커질수록 각 클래스의 역할을 명확히 분리하며 작업하는 것이 정말 중요하다는 것을 뼈저리게 느꼈다.
클래스나 변수의 네이밍이 왜 그렇게 중요한 지도 깨달았다. A 팀원이 삼중 for문에다가 if 문을 넣었던 메서드를 수정해야 했는데 네이밍까지 모호하니까 정말로 이해가 안 됐다.
또, 클린 코딩이 다른 사람이 알아보기 쉽게 하는 것 뿐만 아니라 에러를 탐지하고 문제를 해결할 때 시간을 단축하는 것에 크게 매우매우 큰 기여를 한다는 것을 느꼈다.
그리고 한 편으로는 '코드 리뷰가 조금 더 활발히 이루어졌다면-' 하는 아쉬움이 남기도 했다. 그랬다면 코드 전반에 대한 피드백이 즉각적으로 이루어졌을 것이고, 조금이라도 더 도와드릴 수 있었을텐데🥺
일정의 압박과 코드 리뷰, 테스트 코드 작성에 대한 중요성은 늘 프로젝트의 큰 고민점인 것 같다. 다음에 프로젝트를 하게 된다면 코드 리뷰나 테스트 코드에 대한 부분을 더 설득력있게 어필 해봐야겠다는 생각도 들었다.
나를 돌아보는 시간이었다
그리고 내가 에러를 잡아가는 걸 좋아한다는 것도 알게 되었다! (충격)
팀장님은 이슈가 발생할 때마다 일단 하- 하고 한숨을 쉬는 사람이었다.
그래서 팀 전체의 분위기가 추욱- 가라앉으려고 할 때가 많았던 것 같다. 그리고 나는 그러한 부분들이 해당 상황의 심각성보다 더 크게 팀의 퍼포먼스에 마이너스 요소로 작용한다고 생각했다.
그래서 나는 늘 이렇게 말했다.
"아!! 해결 할 수 있습니다~ 할 수 있어요~"하고 로그부터 살펴보러 갔다.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ활자로 보니까 어색하다
늘 문제를 해결하는 데에 제일 먼저 뛰어들었던 것 같다. 그 에러를 고칠 수 없었더라도 그 과정을 즐기고 있었다.(물론 에러를 잡는 편이 훨씬 기뻤다. 당연함.)
프로젝트가 마무리되고 팀원들의 피드백에서, 문제가 발생할 때마다 긍정적인 말을 많이 했주었던 부분이 프로젝트를 끝까지 완주하는 데 도움이 되었다는 멘트를 많이 받았다. 긍정적인 성격이 팀에 도움이 되어서 기뻤다!!
그리고 팀 프로젝트 자체가 나랑 잘 맞다는 생각도 들었다.
일례로, 프로젝트 초반에는 팀원들이 깃 관리를 어렵고 귀찮은 일로 생각했다.
그래서 그런 오해를 풀고자 나도 같이 공부하고 알려주면서 프로젝트를 진행했다. 깃 관련 문제가 생길 때마다 서로 화면 공유하면서 문제를 찾았고, 명령어에 익숙해질 때까지 경험해보았다.
결국 프로젝트의 막바지에는 팀원 모두가 깃을 어느정도 익숙하게 사용할 수 있게 되었고, 사실은 깃 관리가 내 작업물을 보호해주는 역할도 한다는 걸 다들 알게 되었다!! 신기하면서도 감사해하셔서 나도 기뻤다!!
이처럼, 혼자 해결해야만 하는 일이라면 굉장히 외롭고 막막할 수 있는 일들을 팀원들을 믿고 함께 해결하는 방식이 너무 매력적인 것 같다.
마무리
아직 보완해야 할 부분이 너무너무 많지만 하나의 완성본을 만들어보는 경험이 굉장히 유의미했다. 하면 할 수록 재밌지만 그만큼 하면 할 수록 어려운 것이 개발인 것 같다. 나는 앞으로 어떤 개발자가 될까?
