Refactoring 리팩토링

리팩토링이란 무엇인가?

• 외부동작을 바꾸지 않으면서 내부구조를 개선하는 방법입니다.
• 코드가 작성된 후에 디자인을 개선하는 작업입니다.
• 모든 것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은 디자인을 찾습니다.
• 메소드 내의 지역변수와 파라미터를 주의 깊게 볼 필요가 있습니다.
• 값이 수정되지 않는 변수는 파라미터로 넘길 수 있습니다.
• 값이 수정되는 변수는 주의가 필요합니다. 변화되는 부분을 함수로 추출하여 리턴 값으로 돌려줄 수 있습니다.
• 리팩토링은 작은 단계로 나눠 프로그램을 변경하도록 합니다.
• 네이밍의 중요성. 컴퓨터가 이해하는 코드는 누구나 작성할 수 있습니다.(진짜?!) 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성합니다.(그래야겠죠?)
• 클래스의 메소드는 클래스의 변수를 사용해야 합니다. 클래스의 정보를 사용하고 있지 않는다면 사용하고 있는 변수쪽으로 메소드는 움직여야 합니다.
• 임시변수는 가능하면 제거하는 것이 좋습니다. 임시변수는 종종 쓸데없이 많은 파라미터를 만들어 문제가 되기도 합니다.
• 임시변수를 하나의 메소드로 구현하여 리팩토링하도록 합시다.
• 리팩토링하는 과정에서 알고리즘적으로 성능이 더 안 좋아질 수 있습니다. 하지만 어느 알고리즘 부분이 수정되어야 하는지 명확하게 보이게 되어 최적화하기 더 쉬운 형태로 변경되는 장점이 있습니다.
• 다른 객체의 속성을 기반으로 한 switch문은 좋지 않습니다. 그 부분을 함수로 추출하여 자신의 데이터를 사용하는 것으로 리팩토링 해야합니다.
• 메소드에서 두개의 클래스 변수를 사용하고 있다면 변화하기 쉬운쪽으로 메소드를 이동시켜 변화의 폭을 최대한 작게하는게 좋습니다.
• 기능이 한쪽으로 모여진 클래스를 추상화하여(무슨말이지..) 상속관계로 표현할 수 있습니다.
• state패턴 / strategy패턴 상태를 나타내는지 알고리즘을 나타내는지에 따라 이름이 바뀔 수 있습니다.
• 테스트 -> 리팩토링 -> 테스트 -> 리팩토링 -> 테스트 .. 점진적인 개선으로 진행합니다.

리팩토링의 원리 및 목적

• 소프트웨어를 보다 쉽게 이해할 수 있고 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화없이 내부 구조를 변경하는 것입니다.

유의사항

• 두가지 구별된 작업(기능 추가와 리팩토링)을 위해 시간을 나눠야 합니다.
• 기능을 추가할 때는 기존 코드를 건드려서는 안되고 단지 새로운 기능만 추가해야 합니다.
• 리팩토링을 할때는 기능을 추가해서는 안되고 단지 코드의 구조변경에만 신경써야 합니다.
• 리팩토링을 하는 것보다 코드를 다시 작성하는 게 나을 때도 있음을 기억해야 합니다. 현재 로직을 세부 컴포넌트로 분리하고 리팩토링 할 것을 고려해야합니다.
• 마감시간이 임박할 때는 진행하는 것을 지양해야 합니다.

언제 또는 왜 리팩토링을 해야할까요

• 삼진 규칙(3번의 중복 / 3번의 같은 행위를 한다면 리팩토링을 진행합시다)
• 기능을 추가할때 리팩토링을 합ㄴ디ㅏ.
• 버그를 수정해야 할 때 리팩토링을 합니다.
• 리팩토링을 하면 버그를 찾도록 도와줍니다.
• 중복을 제거함으로써 각각의 작업에 대한 코드가 오직 한 곳에만 있게 할 수 있습니다.
• 코드 리뷰를 할 때 리팩토링을 합시다.

리팩토링 할 때의 문제점

데이터베이스

• 많은 비지니스 로직들은 DB스키마와 매우 의존적입니다.
• 이 문제 해결을 위해서는 호환 객체의 이용을 고려해야합니다.
• 호환 객체의 호환 부분만 수정하면 DB에 덜 의존적일 수 있습니다.

메소드 서명의 변경(디스크립터 변경)

• 이미 많은 곳에서 메소드가 사용되어 모든 서명을 변경하기가 쉽지 않습니다.
• 오버로드를 이용하는 방식은 기존서명을 두고 새 서명을 가진 메소드를 제작 후에 기존 서명은 새 서명으로 옮기도록 변경합니다.
• 그 외에 기존 서명을 사장(Deprecated) 시켜놓고 이유와 해결에 대한 Document를 남깁니다.