2008.12.09 22:31

이 버그를 누구에게 넘겨줄 것인가?에 대한 생각...

우선, 해당 버그를 많이 할당 받은 경험이 있다고 해서, 그 버그에 가장 적합한 사람인지는 한번 쯤 고민해봐야 할 것 같습니다. 반대로, 이미 그렇게 특정 부분에 대한 버그를 많이 할당 받고 있는 상태라면, 벌써 관리자나... 기타 조직 체계가 그 적합한 사람을 알고 움직이고 있다고 볼 수도 있으니까요... 어쨌거나... 가장 적합한 사람은... 누구일까에 대한 고민이 먼저 생깁니다.

대부분의 경우... 버그가 발생하면... "이 부분 누가 개발했어?" 라던가? "이전에 누가 고쳤었어?" 라는 것으로 해서, 그 버그를 생성했을 우려가 있는 사람들을 찾습니다. 이 경우에 단순히 "수정"을 했던 사람은 그 코드에 대해 전체적으로 잘 몰라서 그런 우려를 범했을 수도 있습니다. 오히려, 원래의 개발자나가 더 잘 알고 있는 경우가 많지요.

소스를 클래스 단위로 나눌 수도 있고, 클래스 안에서 다시 또 메소드... 메소드 안에서 또 어떤 기준에 따라 적당한 fragment로 나눌 수 있습니다. 그것을 코드의 조각이라고 하겠습니다. 그리고, 초기에는 각 조각들은 고유한 ID를 가진다고 합니다. ( 뭐 ID를 붙히는 것은 대단한 것이 아니라 코드의 특정 조각의 그냥 Location 정도로 생각해도 되겠습니다. )

해당 소스별로 볼때, 각 조각들의 입장에서 한번 생각해 봅시다. 어떤 조각들은 처음에 만들어져서 아무도 건들지 않고, 깨끗한 상태로 끝까지 살아남기도 합니다. 하지만, 어떤 조각들은 한사람의 손을 거치면서 잘 다듬어지기도 하고, 어떤 조각들은 여러 사람들의 손을 거치면서 좀 지저분해지기도 합니다. 반면, 어떤 조각은 처음과는 전혀 다른 모습으로 바뀌기도 하고, 어떤 조각은 그냥... 사라져 버리기도 합니다. 또 새로운 조각들이 비집고 들어오기도 하구요.

이렇게 각 조각들에는 개발자나 유지보수자들의 흔적이 남게 됩니다.
최초에 그 코드를 생성한 사람의 경우는 그 파트에 대해 최대 점수를 줍니다. 왜냐면, 일단은 그 사람밖에 모르니까요. 그 후에 다른 개발자나 유지보수자들이 그 조각 영역을 수정하거나, 관련된 부분을 고치게 된다면 처음에 개발했던 개발자는 최초의 점수를 수정한 사람에게 빼앗기게 됩니다. 그 코드 조각이 가진 "부동산 지분" 정도라고나 할까요? 그렇게 조각들의 가치나 영향력에 대해서 처음에는 "생성자"가 모두 가지게 되지게 되겠지요.

즉, 각 코드의 조각에 대해서 소유권(부동산이나, 주식의 stock 처럼)을 점수로 주고 받을 수 있고, 해당 조각에 에러가 발생하는 정도나 버그의 빈도 등에 따라서 각 주가(또는 코드 조각 부동산)의 가격(?)은 달라지게 됩니다. 그만큼 그 조각을 소유한 사람의 책임이 무거워지거나 일이 많아진다는 뜻이겠지요. 이러한 것으로 버그를 많이 양산하는 사람을 찾을 수도 있고, 반대로, 버그가 많이 발생하는 지역의 범위를 비쥬얼라이제이션 시킬 수도 있을 것입니다.

그래서, 해당 조각을 기준으로 본다면... 그 조각에 가장 영향을 주거나 잘 알고 있는 사람부터 랭크를 매길 수 있는 것이고... 반대로 "개발자"를 기준으로 한다면 그 개발자가 가장 많이 알고 있는 "조각"들의 지도? 또는 흔적의 모양을 마치 지도의 등고선 모양처럼 볼 수 있을 것입니다.

예를 들면, "아무개"가 가장 잘 알고 있는 코드의 조각들의 패턴을 보여주세요~ ==> 이 패턴을 적당히 또 계산하면, 가장 많이 알고 있는 클래스나 메소드 등을 파악할 수도 있을 것입니다. 이 코드 조각들은 발생하는 버그의 위치와 바로 연결되어 있기 때문에... 버그의 책임 등에 대해 적임자를 찾기 쉬워지겠지요.
또 반대로, 코드의 입장에서  살펴볼 수도 있는 것이구요.

그럴려면, 코드 조각들이 바뀌거나 수정되는 등 유지보수되는 과정에서 발생하는 개발자들의 영향력이 모두 조각별로 점수로 환산되어 계산되어야 합니다. 코드를 살펴본 시간(RFID나 실제 PC의 Activation 여부를 살펴서...) 이나 코드를 넣은 부분들에 대한 정도 등으로 적당한 메트릭을 반영해야겠지요. 그럼, 소스와는 별도로 또는 소스상에 보이지 않도록( 주석 안에 특수 태그를 삽입해서 그러한 경험치들을 남긴다거나... 하는 방법으로 하게 되면, 일반 컴파일러에서도 사용할 수 있음. 그 경험 반영 태그를 지원하는 환경이 아니라면 경험 반영은 되지 않겠지만...)

이러한 경험이 누적되면서, 각 개발자는 소스 코드에 대한 경험이나 영향력 정도에 따라서 어떤 패턴을 가지게되고, 반대로, 각 코드의 일부들도 개발자들의 흔적들이 누적되게 되는 것이겠지요. 자신의 패턴을 살펴보면서 자신의 성향이나... 또는 전체를 알기 위해 더 공부해야하는 부분들을 살펴볼 수도 있을 것입니다.

email을 많이 받거나, 버그를 많이 넘겨 받았다고 해서... 그 사람이 항상 적합한 사람이 될 수는 없습니다. 그렇게 판단해버린다면, 오히려 다른 더 적합한 사람이 실제로 존재하더라도 벗어날 수 없게 되지요. ( 예를 들어, 아주아주 열심히 공부하고, 코드를 수정하고 했다면... 이제는 그 사람이 해당 코드의 버그에 대한 더 적임자가 되는 것이니까요 ) 마치 엉뚱한 solution에서 local optimum을 벗어나지 못하는 것처럼요.

여튼 앞에서의 점수 계산이 가능해서 그러한 패턴을 개발자별로... 또는 소스 입장에서는 개발자의 패턴을 "기억하도록" 만들 수 있다면... 열심히 일하는 사람도 구분할 수 있겠네요. 버그 만드는 사람도 찾고... 개발자로서는 조금 겁나는 일일 수도 있습니다. 감시당하는 느낌이 드는 듯 하니까요.

어쨌거나... 이 버그를 누구에게 넘겨줄 것인가?
- 별로 하는 일 없는 사람?
- 아니면, 일이 많더라도 적임자?

단순히 잘하는 사람에게 넘겨주는 것도 정답은 아닌것 같습니다. 그렇게 되면, 업무가 몰리게 될테니까요.
별로 하는 일 없는 사람에게 해당 영역을 공부하도록 시키고... 그것을 담당하게 하는 것도 좋겠네요. 그럴려면, 어느 부분을 "아무것도 모르는 사람"에게 그냥 공부하도록 시키면 좋을지도 알아야 하는데... 그것은 또 "Dependency" 문제와 관련이 있을 것 같네요. 또는, 라이브러리인지 그냥 UI인지... 핵심 파트인지 아닌지 등도...

여튼, 이 문제는 상당히 재미있는 주제임에는 틀림없습니다. 또한, 한가지 factor만으로는 쉽게 풀리지 않을 것 같습니다. 다양한 조건들에 대해서 Neural network 등을 통해 판단하는 등의 접근이 궁극적으로는 바람직 하지 않을까요?

Trackback 0 Comment 3
  1. swinside 2008.12.09 22:34 신고 address edit & del reply

    1) 코드 조각들을 어떻게 구역을 나누고, 바뀌는 과정에서 어떻게 그 ID들을 유지하거나 변환할지에 대한 고민이 필요합니다. 2) 개발자들의 코드 조각에 대한 "지분"의 가치를 어떻게 평가하고, 어떻게 나누어 가질지에 대한 문제가 있습니다.(첨에 만들었더라도 딴 사람이 완전 고쳐버린다면 첨에 만든사람은 별로 아는게 없겠지요. 이때는 지분이 새로 고친 사람에게 거의 넘어가겠네요.) 3) 코드 입장에서 지분들의 분포, 또는 개발자 입장에서 자신의 지분들의 코드 분포를 어떻게 해석하고, 어떤 의미를 부여할지에 대한 문제가 있습니다. 4) Practical 하게 어떻게 써먹을 수 있을지에 대한 이야기도 많이 나오겠네요.

  2. HannaKim 2008.12.09 23:13 address edit & del reply

    코드의 주인을 찾는 것도 재미나겠군요. 그리고 이부분에 문제가 있을때 가장 적임자를 찾는것도. 특히 몇십년이나 된 코드의 유지 보수는 너무 어려운 일이니.

  3. 제주소년 2008.12.10 19:35 address edit & del reply

    작업의 분할은 디버깅이든 개발이든 어려운 문제 같습니다.. 어떤 분들은 극 소수에 의한 개발이 효율적일수도 있다고 말씀하시는것 같던데요 =ㅅ=a;;