빠르게 개발하면서 일관된 코드 유지하기
위의 그림은 우리 팀 레포지토리의 dev 브랜치의 커밋 이력 중 일부를 캡처한 것이다. 우리 팀의 커밋 이력을 보다보면 위의 그림처럼 merge가 연속적으로 일어나는 것을 종종 확인할 수 있다. 여기서 우리 팀 안드로이드 팀원들의 개발 프로세스를 확인할 수 있다.
우리 팀원들의 pr의 특징은 다들 밤늦게까지 개발을 하고 새벽에 pr이 올라오는 점이다. 이 때의 문제점은 다들 피곤한 시간에 리뷰를 하게 되면 제대로 된 리뷰를 할 수 있다는 보장이 없고 다들 취침시간이 다르기 때문에 리뷰를 다는 시간이 다를 것이라는 점이다. 그렇게 되면 연속적인 대화의 흐름이 생기지 못해 상대방의 의도를 물어보고 다시 토의하고 일관된 코드로 나아가지 못하는 문제가 생길 것 같았다. 예를 들면, 나와 생각이 다른 의도의 코드를 보게 된다면 리뷰로 질문을 하게 될 것이고 이러한 답변이 바로 올 수도 있지만 다음 날 달릴지도 모른다. 이렇게 되면 연속적인 대화가 이루어지지 않는다는 문제로 우리는 인식을 하였다.
이런 문제를 해결하기 위해 안드로이드 팀원들은 매일 스크럼이 끝나고 모닝 리뷰 시간을 가지기로 하였다.
모닝 리뷰 시간에는 다음과 같은 일을 한다.
- 기능을 구현하면서 생긴 고민에 대해 함께 고민하기.
- 상대방의 코드에서 자신과 생각이 다른 점에 대해 방향성 정하기.
먼저, 기능을 구현하면서 생긴 고민에 대해 함께 고민해보는 과정을 통해서 어려웠던 문제를 좀 더 빨리 도출해낼 수 있었다. 3명이 모두 해결법을 찾지 못한 경우에도 나중에 다른 사람이 비슷한 문제를 해결하게 되면 빠르게 공유를 할 수 있는 장점이 있었다.
하나의 예로, 최초 로그인 시에는 홈화면으로 가지 않고 프로필 설정화면으로 이동을 해야한다. 이 때, 프로필 설정화면이 fragment인데, 어떤 activity에서 띄워야할까에 대해 고민을 가지고 pr을 작성하였다. 이 과정에 대해 다 같이 토의하면서 생각한 방법 3가지를 생각했지만, 모두 하나의 문제가 있었다. 이 과정에서 해림님이 추가적인 기술을 공유해주셔서 문제라고 생각했던 부분을 해결함과 동시에 빠르게 문제를 해결할 수 있었다.
또한, 가로 모드에 대한 대응에 대해 고민을 공유하면서 다른 팀원들이 생각하지 못한 문제에 대해 다같이 그 날 각자 해결하는 일도 있었다.
상대방의 코드에서서 자신과 생각이 다른 점에 대한 부분도 리뷰를 진행하면서 실시간으로 방향성을 정할 수 있어서 다음 개발에서 빠르게 적용하여 일관된 코드를 작성하는 데 도움이 되었다. 개발 초반에 개발을 하면서 다른 팀원과 다른 스타일의 코드를 작성하게 될 경우 게더에서서 팀원을 찾아가 얘기를 하고 맞춰나간 후 다시 개발을 했었다. 이 때는, 팀원들의 개발 흐름을 끊는다는 단점과 개발이 느려진다는 단점이 있었다. 모닝 리뷰에서 같이 방향성을 토의하는 시간이 있어서 각자 개발하는 시간에 조금 다른 부분이 있어도 자신의 생각대로 개발을 빠르게 하고 모닝 리뷰 때 방향성을 다시 정할 수 있어서 훨씬 개발속도도 빨라졌다.
우리 안드로이드 팀원들은 모닝 리뷰를 도입함으로써 빠른 개발 속도와 일관된 코드를 지킬 수 있었다!!!
실제로 아래의 그림처럼 모닝리뷰를 도입하고 나서부터 이슈가 닫히는 속도가 빨라짐을 볼 수 있다.
| 예시 | K004 | K016 | K032 |
|---|---|---|---|
| ViewHolder |  |
 |
 |
| Repository 함수 |  |
 |
 |