참고 문서

- CodeComplete2

- 읽기 좋은 코드가 좋은 코드다

- 실용주의 프로그래머

- CleanCode

1. 해당 함수명을 읽었을 때 무슨 역할을 하는 함수인가 기능과 이름을 일치 시키는 것.

   - CreateABC() -> CreateUI() 와 같이 해당 함수가 하는 역할을 이름만 보고 유추할 수 있을 수준으로 작명하자.

2. 각 함수는 하나의 작업만 진행해야 한다.

   - CalcRotation 함수내부에서 Rotation 관련 작업만 처리되어야한다. Scale, Location 등 다른 작업은 그에 맞는 함수를 만들어 작업하도록 하자.

void CalcRotation()
{
	Scale = Set(X Y Z);
    Location = Set(PrevLocation + CurLocation);
    Rotation = Set(Rotation)
}-------------------- X
// 아래와 같이 각 함수 역할에 맞는 함수를 구현
void CalcScale()
{
	Scale = Set(X Y Z);
}
void CalcLocation()
{
	Location = Set(PrevLocation + CurLocation);
}
void CalcRotaiton()
{
	Rotation = Set(Rotation);
}

3. Pair를 갖는 함수인 경우 각 Pair는 서로 동일한 클래스에 위치해야한다.

   - class A::Init() / class A::Reset() or class A::Begin() / class A::End() or class A::Play / class A::Stop() 등 Pair를 이루는 함수는 항상 같은 클래스에 선언 및 구현하자.

class A
{
public:
    void Play();
    void Stop();
    
    void Init();
    void Reset();
    
    void Begin();
    void End();
}

4. 작업하는 모든 사람이 익숙한 방식의 로직으로 설계하도록 노력하자.

   - 그 조직에서 설계된 방식에 맞춰가도록 노력하자. 나만의 로직 및 함수 네이밍을 따라가는 것은 코드를 분석하는데 곤란한 상황이 많이 연출된다.

5. 함수 설계 시 무슨 역할을 하는 함수인지 주석으로 우선 서술 한 뒤 그것을 Code로 변경하고, 함수의 역할이 올바르게 구현되었는지 확인하자. 

  - 내가 설계한 함수를 두번, 세번 검수하는 작업을 거치자.

1. void Add(int a , int b)
{
	// 변수 두개를 더한다.
}

2. void Add(int a, int b)
{
	// 변수 두개를 더한다.
    int result = a + b;
}

3. 정확한 명세대로 구현이 되었는가 확인한다.

6. 상속 클래스를 설계 시 가상함수로 선언 되었으나 함수 내부가 빈 case 가 있는 경우 각 클래스의 상속 관계가 올바른지 다시 한번 확인한다.

   - 빈 함수가 있다는 것은 주로 잘못된 클래스 설계에서 나타난다.

   - Ex) class 전화기

 class 전화기
{
	public:
    전화기();
    ~전화기();
    
    virtual void 전화하기();
    virtual void 전화끊기();
    
    virtual void 번호누르기();
    virtual void 번호지우기();
}
전화기::전화하기()
{
	//전화하기
}

class 핸드폰 : public 전화기
{
	public:
    핸드폰();
    ~핸드폰();
    
    virtual void 전화하기() override;
    virtual void 전화끊기() override;
    
    virtual void 번호누르기() override;
    virtual void 번호지우기() override;
}
핸드폰::전화하기()
{
	//전화하기
}
class 삐삐 : public 전화기
{
	public:
    삐삐();
    ~삐삐();
    
    virtual void 전화하기() override;
    virtual void 전화끊기() override;
    
    virtual void 번호누르기() override;
    virtual void 번호지우기() override;
}
삐삐::전화하기()
{}

▶What?

소프트웨어를 이해하기 쉽고, 수정하기 쉽게 만든다.

기능적으로 소프트웨어의 변경이 없다.

▶Why?

⇒리팩토링은 소프트웨어의 디자인을 개선시킨다.

  - 사람들이 코드를 수정함에 따라 코드는 원래 의도했던 구조를 벗어나기 쉽다. 코드를 보며 원래 의도했던 디자인을 파악하는 것은 점점 더 어려워진다. 리팩토링은 적절한 곳에 있지 않는 코드를 이동 및 제거하여 코드를 정리하는 것이다.

⇒리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.

  - 기계를 위한 코드가 아니라 사람을 위한 코드를 작성한다.

  - 익숙하지 않은 코드를 이해하기 위해서 리팩토링을 하면 전에 보지 못했던 디자인에 관한 것을 볼 수 있게 되며, 더 높은 수준의 이해로 이끌어준다.

⇒리팩토링은 버그를 찾도록 도와준다.

  - 코드를 잘 이해하게 되면 버그를 찾기 쉽다.

⇒리팩토링은 프로그램을 빨리 작성하도록 도와준다.

  - 소프트웨어의 개발 속도를 어느 정도로 유지하기 위해서는 좋은 디자인이 필수다. 리팩토링은 시스템의 디자인이 나빠지는 것을 멈추게 하여, 소프트웨어를 보다 빨리 개발 할 수 있도록 도와준다.

▶When?

⇒기능을 추가할 때 리팩토링을 하라.

  - 추가하기 전에 수정해야 할 코드에 대한 이해를 돕는다. 한번 리팩토링을 하면, 기능을 추가하는 것은 훨씬 더 빠르고, 매끄럽다.

⇒버그를 수정할 때 리팩토링을 하라.

  - 더 깊은 이해를 위해 리팩토링 한다.

  - 별도의 시간을 내서 하는 것이 아니라 '틈틈이 계속적으로' 해야하는 것.

  - 리팩토링은 목적이 아니라 수단이다.