[iOS] 작업을 서로 바꿔서 해보자!
저희는 traveline 서비스 기획 이후에 작업을 어떻게 진행해야 좋을 지에 대한 고민을 지속해서 했어요..!
6주라는 제한된 시간 안에 완성해야하고 목표를 이루면서도, 프로젝트가 그저 나눠서 작업하는 "분업"이 되지는 않을 지 경계했습니다.
저희는 프로젝트가 진행되는 동안 "협업"을 하기 위해서 아래와 같은 방식을 채택하게 되었어요!
우선, 프로젝트 초반에는 전반적인 세팅, 네트워크 레이어 구현, 공통 컴포넌트 개발을 페어 프로그래밍으로 진행하며 서로 흐름을 잡고 저희가 정한 컨벤션들을 바탕으로 코드 스타일을 맞춰갔습니다. 그리고 각자 화면을 담당해 기본적인 UI와 기존에 정한 방식대로 ViewModel의 틀을 만들어오고, 그 이후에는 각자 기존에 담당했던 화면이 아니라 서로 파트를 바꿔 다른 사람이 작성한 코드에 비즈니스 로직과 네트워크 통신을 연결해보기로 했어요!
일단 기본적으로 지금 내가 작성한 코드를 다른 사람이 뒤이어 작성해야한다는 점을 계속 생각하며 작업하다보니, 어떻게 해야 가독성과 재사용에 더 도움이 될 지 항상 신경쓰며 코드를 작성하게 되었어요. 그냥 혼자 쭉 만들었다면 "다음 작업하면서 고쳐야겠다"하고 대충 넘어갈 수도 있는 부분을 그때 그때 잡으면서 작업하다보니 자연스럽게 코드의 퀄리티나 앱의 완성도도 올라갈 수 있었지 않나 싶습니다.
그리고 다른 사람의 코드를 이어서 작업했을 때는 여기서 왜 이런 코드를 사용하셨을까 이해하려고 노력하고, 내가 여기서 코드를 이렇게 수정하면 다른 곳에서 어떤 사이드 이펙트가 발생하지는 않을지 고려하면서 코드를 작성해볼 수 있었어요.
그 전에도 코드 리뷰를 꼼꼼히 진행한다고 생각하고 열심히 코드를 읽었었지만, 막상 실제로 다른 사람 코드에서 추가로 작업해보면서 기존에 코드를 내가 완벽히 이해하고 있지 못했다는 것을 알 수 있었습니다. 그래서 작업을 진행하면서 서로의 코드를 더 깊게 이해해볼 수 있었고, 프로젝트 전반적인 코드의 이해도 또한 높아진 것을 느꼈습니다.
이로 인해 이후 버그 트리아즈와 자체 QA를 진행하며 여러 이슈가 발견되었을 때, 어떤 파트의 이슈를 특정 인원만 수정할 수 있는게 아니라 아무나 해당 이슈를 해결할 수 있어 작업의 병목 또한 막을 수 있었습니다! 🙌
다만 위에서 말한 모든 장점들과 트레이드 오프 관계에 있는 단점은 결국 절대적인 시간은 더 오래 걸린다는 점이었습니다. 저희가 이 방식으로 작업을 해도 될 지 처음에 고민했던 이유이기도 했는데요, 시간은 제한적인데 일정에 너무 큰 영향이 가지는 않을 지 걱정했었습니다.
실제로 해당 방식으로 작업해보니 시간이 더 필요한 것은 사실이었어요. 내 코드를 작성할 때 다른 여러 부분을 더 신경쓰게 되기도 했고, 다른 팀원의 코드를 제대로 이해하는데도 시간이 더 필요했습니다. 그래서 초반에 UI와 ViewModel 틀 작성하는 부분은 우선 분업으로 진행했던게 다행히 유효했다고 생각합니다. 시간이 더 충분했다면 해당 방식을 더 빨리, 더 깊게 시도해봤으면 좋았을 것 같아요!
하지만 해당 방식을 통해 느끼고 배운 점도 많았고, 기존 프로젝트들에서 경험해보지 못한 방식으로 해볼 수 있었던 기회여서 너무 좋은 경험이었다고 생각합니다 😉