[잠깐 홍보]
IT 개발자를 이해하기 위한 모든 개발지식 온라인 강의를 런칭했습니다 :) 현재 오픈 이벤트로 30% 할인 중에 있으니 많은 관심 바랍니다🔥🔥
IT 제품 개발 프로세스 파악하기 #4 - 코드 리뷰 & 충돌 해결
지난 뉴스레터에서 린트, 코드 빌드 과정을 마치면 개발자가 짠 코드가 원격 저장소에 무사히 합쳐질까요? 아쉽지만 코드가 합쳐지기 전까지 추가적인 과정이 있습니다. 바로 코드 리뷰와 Git 충돌 해결입니다.
[참고] 여기서 다루는 개발 프로세스를 반드시 지켜야 하는 것은 아닙니다. 규모가 작은 스타트업 혹은 개인은 짠 코드를 바로 원격 저장소에 업로드하는 경우도 많습니다.
3. 코드 리뷰
보통 개발자들은 본인의 코드를 최종적으로 프로젝트에 반영하기 전에 코드 리뷰를 거칩니다.
코드 리뷰는 다른 개발자들이 직접 본인의 코드를 확인하는 과정을 뜻합니다. 그래서 코드를 보면서 에러가 날 수 있는 코드들을 확인하고 회사의 코딩 컨벤션을 잘 지켰는지도 추가로 확인합니다. 기존의 린트, 코드 빌드 작업이 코드를 확인하는 작업을 자동화해 놓았다면 코드 리뷰는 개발자가 직접 검수하는 과정입니다.
코드 리뷰가 진행된 후 문제가 제기된 코드가 있다면 개발자는 코드를 변경하고 린트, 코드 빌드 작업을 다시 거쳐서 코드 리뷰를 요청하게 됩니다. 보통 코드 리뷰는 Github, Bitbucket 같이 소스코드를 저장하고 관리해주는 서비스에서 진행합니다.
4. 코드 충돌 해결
하나의 프로젝트를 여러 명의 개발자들이 개발하다 보면 같은 파일을 동시에 수정하는 경우가 많습니다.
보통 Git을 사용하면 여러 명의 개발자들이 동시에 동일한 파일을 수정해도 알아서 코드를 합쳐줍니다. 그러나 특정한 상황에서는 병합 과정에서 Conflict(코드 충돌)가 발생합니다.
그때는 코드가 충돌 난 부분을 직접 수정해서 새롭게 코드를 업로드해야 합니다.
개발자가 모자라요 By 영록이 홈페이지
대부분의 IT 회사는 개발자가 부족하다고 이야기합니다. 오늘 소개하는 아티클은 개발자가 부족하다는 문제에 대해 개발자가 직접 반박하는 글입니다. 유명한 경영학 도서 '더 골'에서 다룬 병목자원과 조직 구조 중 하나인 목적 조직을 해결책으로 제시합니다.
- 개발자가 모자라요. 근데 이것도 크게 보면 두 가지 종류가 있다. 스타트업이 개발자를 제대로 구하지 못해서, 혹은 구한 개발자를 붙들어두지 못해서 개발자 공백 상태가 되는 경우. 그리고 또 하나는 개발팀을 그런대로 확보해놓았지만 그 개발팀의 생산성이 만족스럽지 않은 경우. 두 경우의 공통점도 있는데, 그건 개발자가 모자라는 것이 현상이지 원인이 아니라는 것이다.
- 핵심은 병목자원 관리다. 병목자원이란 최종 제품으로 나오는 공정 중에서 생산성이 가장 낮은 공정이다. 이런 병목자원이 있을 때는 병목 자원을 중심으로 프로세스를 짜야 한다. 요는 병목자원에서의 시간 낭비를 제거하는 것이다 ...중략... 이 문제를 개발팀 문제로 치환해보자. 일단 개발팀이 안 받쳐준다는 이야기가 나온다는 것은 개발팀이 병목자원이라는 뜻이다. 사실 개발팀이 얽혀야 하는 대부분의 조직에서 병목자원은 개발팀이다.
- 우선 개발팀이 어떤 식으로 시간을 낭비하게 되는지를 보자. ...중략... 이 문제를 한 마디로 설명한다면 "완벽한 기획서가 존재하지 않기 때문" 이다. 개발자의 책상 앞에 기획서를 수북히 쌓아놓지만 개발자는 그 기획서만으로 개발할 수 없다. 디테일은 늘 빠져있게 마련이다. 그럼 개발하면서 계속 이 기획을 낸 사람과 커뮤니케이션을 해서 필요한 정보를 공급 받아야 한다. 그런데, 그 기획자가 이 프로젝트만 하고 있고, 개발자 옆에 딱 붙어 있어서 필요할 때 바로바로 의문을 해결해줄 수 있으면 되는데, 그런 경우는 드물다.
- 그럼 어떻게 일해야 병목자원, 곧 개발팀의 시간을 낭비하지 않게 할 수 있는가? 제일 중요한 것은 개발자는 기다리는 시간이 없어야 한다는 것이다. 이게 온전히 가능하려면 어쩔 수 없이 다른 사람이 기다려야 한다 ...중략... 프로젝트의 관점에서는 병목자원의 시간은 비병목자원과 100배 이런 차이가 아니라 1과 0의 차이다. 비병목자원 수백 명의 시간보다 병목자원 한 명의 시간이 더 중요하다.
- 그리고 나는 개발팀이 안 받쳐줘서 아무 것도 못한다고 투덜대는 모든 회사들에게서 아주 강력한 공통점을 발견했다. 그것은 기능조직이라는 것이다 ...중략... 목적조직에선 위에서 언급한 많은 문제가 저절로 해결된다. 영업부서에서 개발팀에 요청하는 게 아니라 영업부서에 개발자 한 명이 배치되어 있다고 생각해보자. 그리고 그 개발자는 영업부서의 업무만 처리한다. 그럼 이 개발자에게 과도한 업무가 쌓일 일도 없고, 서로 간에 업무 이해도도 높아지므로 개발자가 정보를 얻기 위해 대기해야 하는 시간도 줄어든다.
의견을 남겨주세요