2011년 2월 18일 금요일

소스코드 Conflict

소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.
하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

댓글 5개:

  1. 음.. 위와 같은 충돌은
    소스코드 법칙을 세우고 서로 맞추는게 오히려 더 맞지 않을까 생각이 됩니다.

    탭간격이라던가 괄호의 규칙 이런걸 정하면 이런 소모적인 충돌은 줄어들테니 말이죠.
    그리고 추가적으로 자주 커밋하고 받으면 이런 문제가 발생할 소지가 줄어 들겠죠 ㅎ

    답글삭제
  2. 구차니님 안녕하세요.
    코딩 컨벤션을 지키는 것은 아주 기본적이고 당연한 것이고 위 내용은 그보다 한단계 높은 수준의 습관입니다. ^^

    답글삭제
  3. 자주 소스코드를 update하는 습관이 일단 중요한 것 같아요.
    그리고 이유 없이(없다기 보단 그냥 미관상이겠죠..) 소스코드의 줄을 맞추거나 라인을 이동하는거 정말 공감합니다..;;ㅎ

    답글삭제
  4. 안녕하세요. 피스티스님
    맞습니다. 팀의 규모가 매우 커지고 프로젝트가 복잡해지면 update를 하는데도 나름 계획이 필요합니다. 파일이 너무 자주 바뀌기 때문에 적절한 시점에 update를 하지 않으면 상당히 복잡해집니다.

    답글삭제
  5. 좋은 글 잘 보고 있습니다.

    개발하는 시간보다 소스코드의 줄맞추는데 시간을 더 많이 소비하는 경향이 있는 일인입니다.
    줄이 안 맞는 코드는 가독성이 많이 떨어지던데..
    이런 경우는 제가 문제가 있는 건가요?

    답글삭제