MoinMoin   리팩토링 UserPreferences
 
Help Info Print View Search Diffs Edit
 인덱스   도움말   찾기   대문   바뀐글 
  1. 목적
  2. 리팩토링
    1. 리팩토링 유형
  3. 관련 서적
  4. 관련 사이트
Since 2009. 2. 1.

목적

리팩토링

  • 이미 작성된 코드에서 리팩토링
    1. 중북 찾기
        중복이 생기는 이유 : 메신저 기능을 담당하고 있는 김과장은 고객의 요청으로 LED에 전화번호를 출력하는 기능을 구현하려고 한다. SMS 모듈에서도 비슷한 기능 구현이 있을꺼라 생각하여 SMS 모듈에서 LED에 전화번호를 출력하는 코드를 찾아보았다. 역시 김과장의 생각대로 동일한 기능을 수행하는 부분이 있었다. 김과장은 늘 그렇듯이 해당 부분을 선택하여 Ctrl-C키를 누르고 파일 브라우저를 변경하여 자신이 작업하는 파일을 선택하여 Ctrl-V를 누른다. 컴파일을 해보니 SMS 모듈에서 사용한 전역변수가 없어서 컴파일 에러가 발생했다. '여기도 하나 추가해야지'라는 짧은 생각 후 전역변수를 하나 추가하여 컴파일을 하니 컴파일 에러가 발생하지 않았다. 폰에다가 넣고 테스트를 하니 제대로 LED에 전화번호가 나타난다. '이제 됐군' 이런 식으로 LED에 전화번호를 보여주는 모듈이 추가 되는 경우 중복된 코드가 생겨난다.
    2. 중복된 부분에 대체할 수 있는 공통의 함수를 작성하여 대체
    3. 의도가 명확히 나타나지 않은 함수명, 변수명 찾기
        의도가 명확하지 않은 함수, 변수명이 생기는 이유 : 팀내에 함수, 변수명 작성에 대한 코딩원칙이나 합의가 이루어지지 않았다. 함수의 경우 동사+명사로 표현되며 각 단어는 대문자로 시작한다라던지... 작명(作名)에 소홀한 이유가 학창시절의 잘못된 교육에서 이유를 찾아본다. 코드가 지저분하더라도 코멘트만 달면 후한 점수를 받을 수 있었다. 아무리 저질 코드라도 코멘트의 양에 따른 코멘트 만능주의, 코멘트로 속죄하고 구원받는 세상이였기 때문이다. '나중에 코멘트 달면 되는데 지금 귀찮게 작명까지 신경쓸 필요없어'라는 생각. 코멘트에 의존하는 것은 현재 작성하는 코드를 깨끗하게 유지하기 위해 들여야 하는 노력을 귀찮아서 나중으로 미루는 것과 같다. 이미 지저분해 진 코드는 시간이 지날수록 수정이 어렵고 나중에 내가 야근을 해야하는 원인이 된다. 음식을 먹고 설겆이를 하지 않고 씽크대에 그저 쌓아두어 벌레들이 들끓게 만드는 것과 같다.
        재밌는 일화 : A프로젝트의 특정 모듈에 int SI, EI; 라는 코드가 들어간 모듈을 B프로젝트에 포팅한 적이 있다. B프로젝트에서는 컴파일 에러가 발생했다. SI이미 define되어 있어 컴파일 에러가 발생한 것이다. 나는 한참 동안 SI가 무엇을 의미하는지 분석을 해야만 했다. 그래야만 SI의 본명을 찾아줄 수 있으리라는 생각이 들었기 때문이었다. 분석후(변수명이 짧아서 이해가 힘들었다) 기존 코드 작성자에게 SI가 혹시 ?StartIndex를 의도한 것인지를 물어보았다. '네'라는 짧은 답변을 얻고나서 SI를 ?StartIndex로 수정하였다.
  • 좋은 코드(Good Code)란?
      나쁜 냄새(Bad Smell)가 나지 않는 코드

'우리팀은 이번에 리팩토링을 했어요.'라는 말을 들으면 나는
'아 리팩토링은 뭔가요?' 라고 묻는다.
'아, 그건요. 코드를 보기 좋게 만드는게 리팩토링입니다.' 라고 자랑스럽게 대답한다.

리팩토링을 했다고 하는 코드들은 다음과 같은 특징이 있더라.

  1. 함수, 변수명이 길어졌음
  2. 테스트로 넣은 코드들을 삭제
  3. ifdef으로 필요없는 코드 삭제
  4. 함수의 하는 일을 표현하기 위해 코멘트 추가
  5. 수행되지 않는 코드 삭제
결론적으로 실제로 컴파일 되지 않는 코드들을 삭제하고 변수명이 바뀌는게 대부분이다.

중복을 제거한다던지 함수를 추출해 낸다던지 하는 일은 거의 없다.

나쁜 냄새(Bad Smell)를 찾는 방법 중에 코드복잡도를 기준으로 하는 것도 좋겠다.

코드복잡도가 높게 나온 코드 = 리팩토링이 필요한 코드

  1. 복잡도가 130인 함수 선정(개발자의 요청)
  2. 시작전 원칙 정하기
    1. 리팩토링 대상 함수가 하는 일 정의
    2. extract method의 naming
    3. extract method의 parameter 사용 방법

Unittest를 진행하면서 복잡도가 높은 함수의 경우 리팩토링 없이 Unittest를 진행하기가 어렵다.
복잡도가 130이라면 하나의 함수에 130개 이상의 test case가 존재해야하기 때문이다. 이런 경우 각 testcase에 대한 이름을 정의하는 것이 불가능하다.
복잡해서 리팩토링의 필요성을 느끼지만 쉽게 리팩토링 진행을 하려하지 않는다.
문제가 발생하는 경우 자신이 책임을 져야하고 현재(?)까지의 문제가 해결된 상태의 코드라는 생각때문이다.
특히 자신이 직접 개발한 코드가 아닌 경우 리팩토링은 상상조차 할 수 없다.
경험한 바로는 주석문이나 Debugging을 위한 메시지 조차도 바꾸는 것을 싫어한다.

리팩토링을 진행하려는 시도를 하려면 먼저 실제 구현 담당자를 설득하는 첫걸음이다.

반복되는 패턴 찾기

if()

    ...
    ...
else if()
    ...
    ...
else if()
    ...
    ...
else
    ...
    ...

조건문에서 처리되는 부분의 경우 일정한 패턴을 가질 확률이 높다.

회사에서 리팩토링을 진행하는 경우 어떤 절차로 진행할 수 있을까?
  1. 사전준비 단계
    1. 전체 소스 코드에 대한 코드복잡도 측정
    2. 함수별 복잡도가 높은 순으로 정렬
    3. 리팩토링 대상에 함수 선정을 위한 복잡도 기준 선정
        예) 10이상의 복잡도를 가지는 함수에 대해서 리팩토링을 실시한다.
  2. 리팩토링 단계
    1. 선정된 함수에 대한 분석
      • line count 측정
      • 함수 이름으로 하는 일에 대한 파악이 가능한가?
      • 하는 일이 무엇인가?
          해당 함수가 현재 처리하고 있는 일들을 간략한 문장들로 표현해 보기.
      • 반복되는 패턴이 있는가?
    2. 리팩토링 해보기
      1. 함수/변수 이름 변경
      2. extract method
      3. 중복제거
      4. ....
  3. 리팩토링 전후 동작에 대한 확인 방안 마련
    1. unittest
        리팩토링 전후 동작 확인을 위해 unittest를 통과하는지를 확인할 수 있음.
    2. 동작 확인
        전후 동작을 실제로 실행시켜보고 확인할 수 있다.

아래와 같은 이슈들에 대해서 생각해 보자.
  1. Refactoring이 먼저냐? Test가 먼저냐?
  2. 어떻게 해야 현재 팀이 계속 Refactoring을 유지할 수 있게 할까?
  3. big change를 피하는 방법
  4. legacy code를 이해하는데 시간이 오래걸리는 문제
  5. Refactoring을 할 수 있는 숙련된 기술자가 있는가?(Refactoring을 할려면 숙련자여야 한다.)
  6. inflection point 어떻게 알지?

리팩토링 유형 

void Process(int WhatCase) 
{ 
    ..... 
    ..... 
    switch(WhatCase) 
    { 
        case 0: 
            .... 
            .... 
            .... 
            break; 
        case 1: 
            .... 
            .... 
            .... 
            break; 
        case 2: 
            .... 
            .... 
            break; 
        case 3: 
            .... 
            .... 
            return; 
    } 
 
} 
 
==========> 
 
void Process(int WhatCase) 
{ 
    ..... 
    ..... 
    switch(WhatCase) 
    { 
        case 0: 
            Do_0(); 
            break; 
        case 1: 
            Do_1(); 
            break; 
        case 2: 
            Do_2(); 
            break; 
        case 3: 
            Do_3(); 
            break; 
    } 
} 
 
함수 Process가 하는 일은 오직 Case에 맞는 Do_x 함수를 호출해 주는 indexing역할만 하기로 정의한다. 
 
간단한 rule을 정해서 반복적으로 리팩토링을 진행해 나간다. 
위험도가 낮고 필요한 parameter만 Do_x 함수에 넣으면 ok. 
시각적으로 깔끔함을 느낌. 
Unittest를 하는 경우 해당 case에 Do_x함수가 불리는가만 test할 수 있음. 
쉬운 리팩토링이지만 의외로 개발자가 섣불지 시도하지 않더라. 실제로 switch문의 case안이 break, return이 복합적으로 존재하고 들여쓰기가 제대로 되어 있지 않아 약간의 두려움을 느끼는 것으로 보임. 


foo() 
{ 
    while(1) 
    { 
        .... 
        .... 
        if() 
        { 
            switch() 
            { 
                case x1: 
                case x2: 
                    .... 
                    .... 
                    break; 
                case x3: 
                case x4: 
                    if() 
                        continue; 
                    break; 
                case x5: 
                case x6: 
                    if() 
                        continue; 
                    break; 
            } 
        } 
        do_something1(); 
        do_something2(); 
        .... 
    } 
}

덩치가 큰 함수에서 extract 하는 경우 큰덩어리로 먼저 분리해 낼 것인지 아니면 작은 부분을 먼저 빼낼 것인지 결정을 해야 한다.
일종의 Top-down이냐 Bottom-up 이냐를 결정하는 순간이다.

Top-down방식이 우선이지 않을까 생각한다.

foo()
{

    ....
    ....
    ....
}
==>
foo()
{
    do_something1();
    do_something2();
}
==>

do_something1()
{

    do_something1_do_something1();
    do_something1_do_something2();
}

do_something2()
{

    do_something2_do_something1();
    do_something2_do_something2();
}

Top-down의 장점 :

  1. 일의 시작점이 명확하다.
  2. 함수의 동작에 대한 그림을 그리기 쉽다.

void foo()
{
    int input;
    while(1)
    {
      ....
      ....
      API_Call(&input);
      ....
    }
}

===>

void foo()
{

    int input;
    while(1)
    {
      do_something1(&input)
    }
}

do_something1(int* input)
{

    ....
    ....
    API_Call(input);
    ....
}

do_something1함수로 추출한 후에 input을 paramter로 사용한다. 추출한 함수 내부에서 API_Call의 parameter에 대한 변경이 필요하다.
do_something1함수에서 API_Call(&input)로 사용하는 경우 어떤 컴파일 에러도 발생시키지 않기 때문에 문제를 해결하는데 시간이 걸릴 수 있음.

void foo()
{
    switch(id)
    {
      case x1:
        Debug_Print();
        break;
      case x2:
        Debug_Print();
        break;
      case x3:
        ....
        break;
    }
    ....
    ....
}

===>

void foo()
{

    switch(id)
    {
      case x1:
        break;
      case x2:
        break;
      case x3:
        ....
        break;
    }
    foo_Debug_Print(id);
    ....
    ....
}

void foo()
{
    if(A == CONDITION1)
      ....
    else if(A == CONDITION2)
      ....
    else if(A == CONDITION3)
      ....
    else if(A == CONDITION4)
      ....
    eles if(B == CONDITION5)
      ....
    else if(B == CONDITION6)
      ....
    else
      ....
}

===>

void foo()
{

    switch(A)
    {
      case CONDITION1:
        break;
      case CONDITION2:
        break;
      case CONDITION3:
        break;
      case CONDITION4:
        break;
      default:
        if(B == CONDITION5)
          ....
        else if(B == CONDITION6)
          ....
        else
          ....
        break;

    }
}

'이 함수가 하는 일은 뭔가요?'
'함수 이름을 지어볼까요?'
'Xxxx를 처리하는 함수입니다.'
보통 함수 이름을 지으라고 하면 Xxxxx_Process 이런식이거나 Xxxxx_Normal_Process 이런식이다.

세상을 다 가질수 있는 함수이름이다.
'너무 방대하네요. 어떤 일을 하는지 명확하지 않구요.'
'워낙 하는 일이 많아서요'

'하는 일을 하나씩 나열해 볼까요?'
'어쩌고 저쩌고 이렇쿵 저렇쿵 하는 일을 합니다.'

하는 일 각각에 대해서 함수 이름으로 나누거나 하는 일의 분리가 힘들경우 하는 일을 나열하는 이름으로 함수 이름을 작성하자. 

void food() 
{ 
    for(i=0; i<MAX; i++) 
    { 
        if(condition1) 
            continue; 
 
        if(condition2) 
            continue; 
 
        if(condition3) 
            continue; 
 
        if(API_Call(i)) 
            continue; 
 
        .... 
        .... 
    }        
} 
 
===> 
 
void foo() 
{ 
    for(i=0; i<MAX; i++) 
    { 
        if(IsSkipCondition(...)) 
            continue; 
        .... 
        .... 
    }        
} 
 
IsSkipCondition(int index, struct A) 
{ 
    BOOLEAN isSkipCondition = FALSE; 
    if(condition1) 
        isSkipCondition = TRUE; 
    else if(condition2) 
        isSkipCondition = TRUE; 
    else if(condition3) 
        isSkipCondition = TRUE; 
    else if(API_Call(index)) 
        isSkipCondition = TRUE; 
 
    return isSkipCondition; 
} 
 
API_Call 때문에 for 루프의 index를 넘겨줘야 해서 왠지 깔끔하지 않아 보인다.

리팩토링에서 함수를 추출하는 경우 parameter가 많아지는 경우가 생긴다.
이럴 때 어떻게 해야할까?
paramter수가 많아지더라도 일단 기존 동작에 가장 가깝게 수정하여 동작을 확인한다.
paramter수가 많은 함수를 다시 리팩토링을 해서 parameter수를 줄여나간다.

한꺼번에 함수를 추출하고 parameter까지 없애려고 하기 보다는 하나의 목표를 정하고 그 목표를 충실히 달성하는 방향으로 진행하는 것이 안정적이다.

이틀동안 모듈담당자와 리팩토링을 진행하다가 오늘은 혼자서 진행했다. 함께 작업하다가 혼자하는 경우 장단점은 무엇일까?
  1. 장점
    • 자리가 편하다.
        좁은 자리에 큰 의자가 들어가다보니 앉아 있는 자세가 불편했다. 혼자서 편하게 앉아서 작업하니 덜 피곤하다.
    • 키보드, 마우스
        키보드, 마우스를 번갈아 가면서 사용하다보니 불편한 점이 있었다.
    • 에디터프로그램
        에디터프로그램에서 사용하는 단축키 등의 설정이 나의 작업 환경에 맞춰져있어서 검색, 복사, 붙여넣기 등의 작업이 더 빠르다.
  2. 단점
    • 리팩토링 대상 함수에 대한 정보를 얻기가 힘들다.
    • 리팩토링할 함수 작명
        대상 함수에서 특정부분을 추출해 놨지만 마땅히 어떤 이름으로 지어야 할지 고민이다.

'이 함수가 하는 일이 뭔가요?'
'음... 전반적인 처리를 합니다.'
'좀 구체적으로 이야기 해줄 수 있나요?'
'음...'

복잡한 함수는 솔직히 담당 개발자도 정확히 파악을 못하고 있는 경우가 많다.
그럼 상태에서 함수의 정의를 내려달라는 것은 너무 무리한 부탁이라 생각한다.

한가지 고안한 방법은 함수의 큰 그림을 같이 그려보는 것이다.

foo()
{

    if(국내)
    {
    }
    else
    {
    }

    switch()
    {

      case x1:
        break;
      case x2:
        break;
      case x3:
        break;
    }

    if(아날로그)
    {
    }
    else
    {
    }

    if(아날로그)
    {
    }
    else
    {
    }

    if(아날로그)
    {
    }
    else
    {
    }

}

==>
foo()
{

    if(국내)
    {
    }
    else
    {
    }

    switch()
    {

      case x1:
        break;
      case x2:
        break;
      case x3:
        break;
    }

    if(아날로그)
    {

      do_something1_아날로그();
      do_something2_아날로그();
      do_something3_아날로그();
    }
    else
    {
      do_something1_디지털();
      do_something2_디지털();
      do_something3_디지털();
    }
}

이렇게 1-2 depth 정도 수준에서 그 함수가 하는 일을 정의하면 쉬워진다.

  • 위와 같은 아웃라인을 잡아주는 간단한 유틸리티를 만들어볼 수 있겠군요!. 너무 많은 디테일때문에 눈에 들어오지 않는 것인데, 그것들을 적당히 감춰줄수 있다면 코드상의 패턴이 더 잘 드러나보이고, 리팩터링을 할 만한 힌트를 얻을 수 있을 것 같습니다. --한주영

복잡한 함수를 리팩토링하다보면 실수를 하기 마련이다.
컴파일 에러가 나기도 하고 혹은 정상적인 동작이 안되는 경우도 있다.
보폭을 작게 하더라도 문제를 발생하기 마련이다.
리팩토링을 코칭하는 경우 문제가 발생하면 개발자는
'이거 괜히 한거 아냐?'
'혹시 side effect도 있는거 아냐?'
'이거 왠지 불안한데'
이런 반응을 보인다.

이런 경우도 있었다.
담당자와 함께 리팩토링을 한 소스를 update하다가 문제가 발생한 적이 있다. 담당자는 한숨을 쉬며 어쩔 줄 몰라했다.
담당자 옆 자리에 다른 기능 개발자가 있다.
며칠 동안 우리가 즐겁게 작업하는 것을 봐왔지만 그다지 긍정적으로 보는거 같지는 않았다.
마침 그 사람이 우리에게 몇 마디 말을 건넸는데
'음 거봐라 리팩토링하다가 잘못되면 그렇게 된다.'
이런 느낌을 받았다.

부정적인 느낌이 담당자에게 가지 않도록 최대한 침착하게 대응했다.
'바뀐 부분 체크해 보죠. 바뀐게 별로 없으니 금방 찾아낼 수 있을껍니다.'
약 10분 정도 작업만에 문제를 해결하고 우리 두 사람은 기쁜 마음으로 퇴근한 적이 있다. 

foo() 
{ 
    int i; 
     
    .... 
    .... 
    .... 
    i = AssignValue(); 
    .... 
    .... 
 
    .... 
    .... 
    if(i == CONDITION1) 
    .... 
} 
 
===> 
foo() 
{ 
    int i; 
    i = do_something1(); 
    do_something2(i); 
} 
do_something1() 
{ 
    int i; 
    .... 
    i = AssignValue(); 
    .... 
    return i; 
} 
 
do_something2(int i) 
{ 
    .... 
    .... 
    if(i == CONDITION1) 
    .... 
} 
 


foo() 
{ 
    if(CONDITION1) 
    { 
        .... 
        .... 
        .... 
        .... 
        .... 
        .... 
        .... 
    } 
} 
 
===> 
 
foo() 
{ 
    if(CONDITION1) 
    { 
        do_Something1andSomething2(); 
    } 
} 
 
do_Something1andSomething2() 
{ 
        .... 
        .... 
        .... 
        .... 
        .... 
        .... 
        .... 
} 
 
unittest가 없는 경우 보폭을 짧게 나갈 필요가 있다. 
실제로 개발자와 같이 작업을 하면서 해당 부분의 하는 일에 대해서 물어보았다. 
'이 부분은 무슨 일을 하는 부분인가요?' 
'Something1과 Something2를 하는 부분입니다.'라고 자신있게 말한다. 
'그럼 Something1과 Something2를 나눌 수 있겠군요.' 
개발자는 소스를 찬찬히 훝어보았지만 짦은 한 숨을 내쉬며 
'음... 이 부분은 호출되는 순서도 중요하고 이건 생각을 좀 해봐야겠는데요' 
하지만 소스를 살펴보니 Something1과 Something2가 쉽게 분리하기 어려운 구조로 군데군데 섞여 있었다. 
자칫 보폭을 크게 나갔다가는 정상동작을 보장하기가 힘들겠더라. 
그래서 다음 단계로 do_Something1andSomething2라는 이름으로 extract method로 1단계 리팩토링을 마쳤다.

개발자는 항상 바쁘다.
'양산 문제가 터져서요. 지금은 시간이 없습니다.'
'나중에 하면 안될까요? 지금 할 여력이 없어요.'
'중요한 일인지는 알겠는데요... 지금은 좀...'

이런 말을 남기고 다시 복잡한 코드에서 문제점을 찾기 위해서 이리저리 디버깅하는 모습이 너무 안타깝다.

리팩토링을 제안할 때
'같이 하시죠'
'제가 일단 리팩토랭을 진행해 볼께요'
라는 말을 한다.

달라진 코드의 모습을 보면 개발자도 긍정적으로 바뀌긴 하더라.
리팩토링은 개인이 책임지고 하는 것보다 함께 위험에 대한 요소를 분담해 가면서 진행하는게 좋은거 같다.
특히 pair로 진행하는 경우 시간 소요는 있지는 개발자와 나 모두 안정감을 가지더라. 

foo() 
{ 
    .... 
    .... 
    .... 
    for() 
    { 
        .... 
        if() 
        { 
            .... 
            if() 
            { 
                .... 
                return FALSE 
            } 
            .... 
        } 
        else 
        { 
            .... 
            if() 
            { 
                .... 
                return FALSE 
            } 
            .... 
        } 
         
        .... 
    } 
    .... 
    .... 
} 
 
====> 
 
foo() 
{ 
    .... 
    .... 
    .... 
    if(do_something1() == FALSE) 
        return FALSE; 
    .... 
    .... 
} 
 
bool do_something1() 
{ 
    for() 
    { 
        .... 
        if() 
        { 
            .... 
            if() 
            { 
                .... 
                return FALSE 
            } 
            .... 
        } 
        else 
        { 
            .... 
            if() 
            { 
                .... 
                return FALSE 
            } 
            .... 
        } 
         
        .... 
    } 
    return TRUE; 
}

어제 리팩토링 관련 이야기를 하다가 개발자가 대뜸 이런 이야기를 했다.
'좀더 일찍 만났더라면 좋았을텐데요. 많이 아쉬워요'
그 개발자는 좀더 많은 부분을 리팩토링하고 싶어한다. 현재 출시 일정으로 모든 함수에 대해서 리팩토링을 하지 못하는 것이 아쉽다고 한다.

'파일을 분리하면서 전역변수로 사용해야 할꺼 같아요'
'저는 예전에 개발할 때 전역변수를 전혀 사용하지 않았어요. Set/Get으로 사용하는건 어떨까요?'
'전역변수가 편하지 않나요?'
어제 개발자와 이런 대화를 나누었다.
리팩토링을 진행하면서 큰 사이즈의 파일을 나누는 작업을 하고 있었다.
파일을 나누다보면 파일 내에서 static 변수로 사용하던 놈을 분리한 파일에서 참조해야 하기에 이런 고민을 하게 되더라.

'디버깅 관점에서도 Set/Get은 의미가 있습니다. 보통 디버깅에서 중요한 것은 해당 변수에 새로운 값으로 assign하느냐 아니면 해당 변수값을 그냥 참조만 하느냐 입니다.
디버깅을 위해서 trace 메시지를 찍더라도 보통 확인하는 것은 해당 변수에 특정 값이 assign되는 시점을 찾기 위해 하는 디버깅이 많죠. 함수이름이 Set변수명인 경우를 찾으면 해당 변수에 값이 assign되는 경우를 쉽게 찾을 수 있어요. 현재 처럼 전역변수를 사용하는 경우 해당 변수를 사용하는 경우를 모두 검색해야 하고 또 assign이 일어나지는 참조가 일어나는지를 눈으로 모두 확인해 봐야하겠죠. 디버깅을 할 때 Set함수에만 특정 조건을 준다면 원하는 경우를 쉽게 찾아낼 수 있어요. 특히 시스템 프로그램이나 m/w 개발을 할 때 아주 유용하다고 생각합니다.'

* switch의 return 제거 (2009. 6. 25) 

foo() 
{ 
    switch(condition) 
    { 
        case 1: 
           .... 
           .... 
           return; 
        case 2: 
           .... 
           .... 
           return; 
        case 3: 
           .... 
           .... 
           return; 
        case 4: 
           .... 
           .... 
           break; 
        case 5: 
           .... 
           .... 
           break; 
    } 
    .... 
    .... 
    .... 
} 
 
===> 
foo() 
{ 
    switch(condition) 
    { 
        case 1: 
           .... 
           .... 
           return; 
        case 2: 
           .... 
           .... 
           return; 
        case 3: 
           .... 
           .... 
           return; 
        case 4: 
           .... 
           .... 
           break; 
        case 5: 
           .... 
           .... 
           break; 
    } 
    do_something(); 
 
} 
 
===> 
foo() 
{ 
    switch(condition) 
    { 
        case 1: 
           .... 
           .... 
           break; 
        case 2: 
           .... 
           .... 
           break; 
        case 3: 
           .... 
           .... 
           break; 
        case 4: 
           .... 
           ....           
           do_something(); 
           break; 
        case 5: 
           .... 
           .... 
           do_something(); 
           break; 
        default: 
           do_something(); 
           break; 
    } 
} 
 
===> 
foo() 
{ 
    switch(condition) 
    { 
        case 1: 
           do_case1(); 
           break; 
        case 2: 
           do_case2(); 
           break; 
        case 3: 
           do_case3(); 
           break; 
        case 4: 
           do_case4(); 
           break; 
        case 5: 
           do_case5(); 
           break; 
        default: 
           do_something(); 
           break; 
    } 
} 

 
foo() 
{ 
    .... 
    .... 
    .... 
     
    if(flag & flag2) 
    { 
        if(flag && ...) 
        { 
           .... 
           .... 
           return; 
        } 
        if(flag && ...) 
        { 
           .... 
           .... 
           return; 
        } 
        .... 
        .... 
    } 
     
    if(flag && ...) 
    { 
         .... 
         .... 
         return; 
    } 
 
    if(flag && ...) 
    { 
         .... 
         .... 
         return; 
    } 
 
    if(flag && ...) 
    { 
         .... 
         .... 
        return; 
    } 
    .... 
    .... 
} 
===> 
 
foo() 
{ 
    .... 
    .... 
    .... 
     
    if(flag & flag2) 
    { 
        if(flag && ...) 
        { 
            do_something1(); 
            return; 
        } 
        if(flag && ...) 
        { 
            do_something2(); 
           return; 
        } 
        do_something7(); 
    } 
     
    if(flag && ...) 
    { 
         do_something3(); 
         return; 
    } 
 
    if(flag && ...) 
    { 
         do_something4(); 
         return; 
    } 
 
    if(flag && ...) 
    { 
        do_something5(); 
        return; 
    } 
    do_something6(); 
} 
GetCondition() 
{    
    if(flag & flag2) 
    { 
        if(flag && ...) 
        { 
            return condition1; 
        } 
        if(flag && ...) 
        { 
            return condition2; 
        } 
        do_something7(); 
    } 
     
    if(flag && ...) 
    { 
        return condition3; 
    } 
 
    if(flag && ...) 
    { 
        return condition4; 
    } 
 
    if(flag && ...) 
    { 
        return condition5; 
    } 
    return condition6; 
} 
 
foo() 
{ 
    condition = GetCondition(is_do_something7) 
 
    if(is_do_something7 == TRUE) 
        do_something7(); 
 
    switch(condition) 
    { 
        case 1: 
           do_something1(); 
           break; 
        case 2: 
           do_something2(); 
           break; 
        case 3: 
           do_something3(); 
           break; 
        case 4: 
           do_something4(); 
           break; 
        case 5: 
           do_something5(); 
           break; 
        case 6: 
           do_something6(); 
           break; 
    } 
} 


switch문 중간에 #ifdef가 들어가 있는 보기 좋게하는 방법이 없을까? 
 
foo() 
{ 
    switch(condition) 
    { 
        case 1: 
            break; 
        case 2: 
            break; 
        case 3: 
            break; 
        case 4: 
            break; 
#ifdef OTHER_CONDITION 
        case 5: 
            break; 
        case 6: 
            break; 
        case 7: 
            break; 
#endif 
        case 8: 
            break; 
        case 9: 
            break; 
        default: 
            break; 
    } 
}

보통 if.. else if.. 등으로 조건이 여러겹 중첩되는 경우 switch문으로 변경가능한 경우가 많다.
switch문으로 수정하면 코드가 좀더 보기 쉬운거 같다. 

void foo() 
{ 
    .... 
    .... 
    if(a>b) 
        return 1; 
    else if(b>a) 
        return -1; 
    .... 
    .... 
    if(c>d) 
        return 1; 
    else if(d>c) 
        return -1; 
    .... 
    .... 
    if(e>f) 
        return 1; 
    else if(f>e) 
        return -1; 
    .... 
} 
 
#define CompareMoreOrLess(a,b){    \ 
    if(a>b)                        \ 
        return 1;                  \ 
    else if(b>a)                   \ 
        return -1;                 \ 
} 
 
void foo() 
{ 
    .... 
    .... 
    CompareMoreOrLess(a,b) 
    .... 
    .... 
    CompareMoreOrLess(c,d) 
    .... 
    .... 
    CompareMoreOrLess(e,f) 
    .... 
}

대부분의 작업이 길이가 긴 함수를 작게 쪼개는 일이다.
물론 함수이름을 개발자와 함께 신경써서 짓고 중복이 되는 것을 제거도 했다.
3주 정도 진행하다보니 초반의 희열은 이제 약간의 귀찮음으로 변했다.

'뭔가 다른 것이 없을까?'

개발자와 이야기하면서 필요하다고 생각되는 부분은
기존코드에 새로운 기능을 추가하는 경우 어떤 식으로 추가해야할까? 

string, time, bit 등과 관련된 자주 사용하는 연산에 대한 리팩토링 패턴이 필요함. 
아래 예제에는 time과 string에 관련된 자주 사용하는 예제. 
 
void GetStringTimeFormatByTime(A_CHAR* szTime, int nHour, int nMinute, BOOL b12Hours) 
{ 
    BOOL bPM = FALSE; 
 
    if (b12Hours) 
    { 
        if (nHour >= 12) 
        { 
            bPM = TRUE; 
            if (nHour > 12) // 13:00~23:00 => 01:00~11:00 pm 
            { 
                nHour -= 12; 
            } 
        } 
        else 
        { 
            bPM = FALSE; 
            if (nHour == 0) // 00:00 => 12:00 am 
            { 
                nHour = 12; 
            } 
        } 
    } 
 
    // HH:MM or HH:MM XX (XX => AM or PM) 
    szTime[0] = '0' + (nHour / 10); 
    szTime[1] = '0' + (nHour % 10); 
    szTime[2] = ':'; 
    szTime[3] = '0' + (nMinute / 10); 
    szTime[4] = '0' + (nMinute % 10); 
 
    if (!b12Hours) 
    { 
        szTime[5] = '\0'; 
    } 
    else 
    { 
        if (!bPM) 
        { 
            szTime[5] = 'A'; 
        } 
        else 
        { 
            szTime[5] = 'P'; 
        } 
 
        szTime[6] = 'M'; 
        szTime[7] = '\0'; 
    } 
} 
 
===> 
void GetStringTimeFormatByTime(A_CHAR* szTime, int nHour, int nMinute, BOOL b12Hours) 
{ 
    BOOL bPM = FALSE; 
 
    if (b12Hours) 
    { 
        bPM = (nHour >= 12); 
        nHour = nHour % 12; 
 
        if (nHour == 0) // 00:00 => 12:00 am 
        { 
            nHour = 12; 
        } 
    } 
 
    SPRINTF(szTime, L"%02d:%02d", nHour, nMinute); 
 
    if(b12Hours) 
    { 
        SPRINTF(szTime+5, L"%s", (bPM)?L"PM":L"AM"); 
    } 
}

관련 서적

관련 사이트

PythonPowered EditText of this page (last modified 2010-01-04 20:10:40)
FindPage by browsing, searching, or an index
Or try one of these actions: DeletePage, DeleteUploadedFile, LikePages, SpellCheck, UploadFile