그 중에서도 나를 가장 힘들게 했던 것은 하기와 같은 상황이 자꾸 발생하는 것 때문이었다.
상황: 한 인도 개발자가 있다. 나와는 다른 기능팀이다. 해당 개발자가 자신이 수정한 코드를 메인라인에 올렸다. 그런데 해당 개발자가 수정한 코드로 인하여 태스크 스케쥴링이 안되고, 다른 기능들이 동작하지 않는 경우가 생겼다.
메인 라인이 자꾸 깨지는 것이다. (아직 프로젝트 초반이라 해당 프로젝트의 테스트 자동화는 CI (Continuous Integration)에 포함되지 못했다.) 처음 한 두번은 그럴 수도 있지하고 넘어갔지만, 이런 일이 자꾸 벌어졌다. 메인라인이 오동작하거나 동작하지 않는 상황이 거의 매일 발생하고, 그로 인하여 다른 개발자들의 업무는 자꾸 지체됐다.
진짜 상기 상황도 한 두번이지.... SW 릴리즈가 며칠 남지도 않은 상황에서 이런 일이 거의 매일 반복되면 진짜 짜증이 이만 저만이 아니다. 한동안 SW 릴리즈 되기 전까지 해당 특정 인도 개발자의 이름이 정말 하루에도 몇번씩 오르락 내리락 거렸다. 아마 그 인도 개발자의 수명은 많이 연장 되었으리라.... 한국에서 살았다면 거의 영생을 누리지 않았을까 싶다.... -_-;;;
첫번째 SW 릴리즈 후, (참고로 이번 신규 프로젝트가 이직 후, 초기부터 관여하여 개발에 참여하는 나의 첫 프로젝트이다) 이 문제에 대해서 곰곰히 생각해 보았다. 다음 프로젝트는 과연 이런 문제를 안겪고 잘 개발할 수 있을까? 한 개발자의 잘못으로 다른 개발자들이 피해를 입게 되는데 이런 상황을 피할 수는 없을까?
내가 관리자도 아닌데, 이런 걸 고민하고 있다는게 좀 웃기긴하다. 그런데 이번에 개발하면서 너무 짜증나고 힘들어서 이런 경험을 또하고 싶지는 않다는 생각이 너무나 강하게 들었다. 그래서 원인과 함께, 개선할 사항이 뭐가 있는지 생각해보았다.
1. 문제를 자꾸 일으킨 인도 개발자는 해당 기능에 대해서 최근에 교육받은 신규 개발자다. 자신이 맡은 기능이 다른 기능들에 어떻게 영향을 미치는지 정확히 잘 알지 못한다.
=> 간단히 말하면 본인이 맡은 기능에 대한 이해도가 미흡한 개발자를 어떻게 할 것인가? 이다. 가장 좋은 방법은 해당 인도 개발자에게 코드 리뷰와 조언을 해줄 개발자를 붙여준다는 것이다. 하지만.... 현재 그 인도 개발자가 속해있는 기능 팀내에 그렇게 해줄 수 있는 능력을 지닌 개발자가 없다....
이건 사실 옆에서 지켜본 나의 지극히 개인적인 의견이다.... 만약 이런 내용을 회사에서 쪼랩 개발자인 내가 대놓고 말한다면 그 기능팀과 싸우자!라고 말하는 것과 다를 바 없고, 또한 나의 능력 범위 밖이므로..... 그냥 조용히 가슴에 묻는다.
 |
| < 위의 말을 절대 입밖으로 소리 내서는 안된다...> |
2. 우리 회사는 보통 각 기능마다 코드를 변경할 때, 함께 업데이트해야 하는 확인 문서 들이 있다. 코드 리뷰 확인 문서 부터 시작해서 테스트 리포트 까지... 간단한 소스 코드 수정에도 4가지 정도의 확인 문서를 함께 업데이트 해야 한다.
그런데!!! 해당 인도 개발자가 맡은 기능이 general한 기능이고, 플랫폼과 직접적으로 관련된 기능이어서 해당 문서들이 없다. 이 말인 즉 다시 말하면, 소스 코드 수정한 이후에 어떤 것을 테스트할지, 어떤 부분을 코드 리뷰 받아야 할 지가 문서로 정해져 있지 않다는 것이다.
=> 다른 기능과 마찬가지로 해당 기능에도 확인 문서를 작성하고, 소스 변경 시 꼭 해당 문서를 업데이트 하도록 한다.
3. 해당 프로젝트의 테스트 자동화를 빠른 시일내에 CI에 포함 시킨다.
블로그내 관련 글
1. 원거리 인도 개발자와의 협업 (1) - 좋은 질문 하도록 유도하기
2. 원거리 인도 개발자와의 협업 (2) - 좋은 질문하도록 유도하기의 후기글
3. 원거리 인도 개발자와의 협업 (3) - 재현 안되는 문제 분석하기
0 개의 댓글:
댓글 쓰기