개발조직의 팀장을 하다보면 언젠가 이런 충동에 맞닥뜨리게 됩니다. 「우리팀 코드들을 보니 두서가 없고 엉망이야. 리펙토링(Refectoring)!!! 하고 싶다. 아주 강력하게 하고 싶다.」

그래서 실제로 팀장 혼자서 날밤을 새가며 코드 개선 작업을 하고 있고 이 글을 쓰는 저도 그런 작업을 한 경험이 있습니다.

하지만 리팩토링에 대한 반대 의견들도 많습니다. 뒷이야기긴 하지만 예전에 세이 클럽이라는 곳에서 싸이월드와 똑같은 서비스를 6개월 전에 완성했지만 개발팀의 강한 리팩토링 요청에 의해 오픈이 늦어졌고 결국 싸이월드측에서 먼저 서비스를 내놓는 바람에 빛을 못봤다는 이야기도 있습니다. (이것은 당시 세이클럽 기획자의 주관적인 이야기 입니다)

특히 운영중이고 코드가 양이 많으면.. 이를 선별하는 기준도 쉽지 않습니다. 하지만 얼마전 현해탄 건너 후지 제록스에서 이런 리펙토링 기준에 대하여 발표한 내용이 있어 공유해 봅니다.

이 내용의 전제 조건은 『현재 운영중인, 1000만 라인 이상의 규모』입니다. 기준은 소스 복잡도와 일정 기간 동안의 커밋 횟수로 잡습니다.

복잡도 기준은 사이클로매틱 복잡도(McCabe Complexity)를 사용하며 10을 넘어가면 위험하다고 합니다. 커밋 수는 해당 조직에서의 커밋 횟수 최대치, 최소치를 x축에 Arrange를 하면 될 것 같습니다.

각 사분면의 내용을 설명하면 다음과 같습니다.

  1. 위험 부분 : 우선적으로 리팩토링을 수행한다
  2. 잠재적인 부분 : 일단 보류하는 부분. 전체적으로 수정이 발생시 같이 수행한다.
  3. 주의해야 할 부분 : 변경 포인트를 줄일 수 있다면 문제 없음. (줄일 수 없다면 리팩토링 고려)
  4. 문제 없는 부분 : 리팩토링 불요 일본어 원문에는 복잡도 측정을 『Understand』같은 고가의 툴을 이용하여 구한다고 합니다. 제가 보기에는 복잡도만 구하려고 후지제록스 측에서 『Understand』를 산 것 같지는 않고, 이미 다른 목적으로 구매한 툴을 여기에 활용하는 것 같습니다.

무료 도구(NSIQCollector등)등을 사용하여 코드의 복잡도를 구하고, 커밋 횟수를 조사하고 기준을 만들면 위와 같은 매트릭을 만들 수 있습니다. 제가 생각하기에는 2가지 장접이 있습니다.

  1. 개발품질관리자 입장에서는 리팩토링에 대한 명분을 가져온다
    • 위험 부분을 구체적으로 파악하고 이에 대한 제시를 한다면 의사결정자들에게 설득이 쉽습니다.
  2. 리소스 낭비를 막는다.
    • 자칫 리팩토링으로 인해 발생할 수 있는 위험들(일정 지연 등)에 대하여 효과적으로 대응 가능

리팩토링으로 고민중인 분이 계시면 한 번 고려해 보심이..