일단 내용을 정리하기에 앞서 내가 추천받은 책을 한 권 소개를 하려고 한다. 추천해 주신 분은 같이 개발하시는 선임님께서 먼저 읽어 보고 추천을 해주셨고 구매를 하게 되었다.
책의 내용을 간략하게 소개하자면 책을 지은 사람은 마틴 파울러라는 ThougthWorks의 수석 과학자이며 우리가 개발을 하면서 한 번쯤은 들어본 IOC(제어 역전)와 DI(의존성 주입)의 용어를 대중화시킨 분 이시다. 😲
리팩터링에 대해서, 리팩터링의 이유, 리팩터링을 해야 할 곳을 찾고 싶다면?, 리팩터링 실습 등 내용이 굉장히 알차다. 물론 책을 한번 쭉 정독했다고 해서 개발된 소스를 다이내믹하게 수정한다거나 바로 눈에 띄는 곳이 별로 없을 수 있지만 개발을 하면서 "아 이거 책에 있었던 거 같은데 한번 봐야겠다." 하면서 계속해서 찾아볼 수 있는 책이라고 생각을 한다. (요즘은 자주 안봄...😅)
⚡리팩터링에 대해서
소프트웨어 개발에서 겉으로 드러나는 코드의 기능(겉보기 동작)은 바꾸지 않으면서 내부 구조를 개선하는 방식
리팩터링은 쉽게 말해 작업된 코드의 내용을 쉽게 이해하고 유지보수에 좋게 초점을 맞춰서 수정하는 작업이라고 이해하면 편할 거 같다. 개발자라면 다른 사람이 짜놓은 코드를 분명 한 번쯤은 보게 되는데 이때 마음속으로 "왜 이렇게.. ㅅ..🍉" 해본 경험이 있을 것이다. 누군가는 내 코드를 보고 저런 생각을 했을지도 모른다.
개발을 해놓은 소스를 보고 회사의 다른 개발자분들이 이해를 못 하시지는 않을까? 이상하지는 않은가? 이런 고민을 항상 가지면서 코딩을 하고 리팩터링에 접근을 하게 되었다. 정상적인 개발자라면 안 바쁜 개발자는 없다고 생각을 하는데 바쁘다는 이유, 귀찮다는 이유로 소스에 생각을 안 하고 그냥 생각나는 데로 코딩을 하게 되면 나중에 유지보수 단계에 가서 소스를 수정하려고 한다면 엄청난 노력과 시간이 소요될 수밖에 없다고 생각을 한다.
⚡리팩터링 목적
- 코드의 가독성 개선 : 복잡한 코드를 단순하게 만들어 가독성을 높인다.
- 코드의 재사용성 개선 : 중복된 코드를 제거하고 유용한 기능을 재사용할 수 있는 코드를 작성한다.
- 유지보수성 개선 : 코드를 단순화하고 구조를 개선하여 코드를 수정하고 유지보수하기 쉽게 만든다.
- 버그 수정 : 리팩터링을 통해 발생한 버그를 찾아 수정하고, 코드를 테스트하여 오류를 최소화한다.
- 개발 생산성 향상 : 코드를 단순화하고 구조를 개선하여 개발자가 새로운 기능을 빠르게 구현할 수 있도록 돕는다.
리팩터링은 기존의 코드를 변경하기 때문에, 코드를 처음부터 재작성하는 것보다 비용과 시간이 적게 든다. (아닌 경우도 있다..😭)
목적을 명확히 하고 개발되어 있는 소스의 상태를 보면서 리팩터링을 하는 것이 중요하다고 생각한다.
⚡리팩터링 기법
- 메서드 추출(Method Extraction) : 코드 블록 내에 존재하는 기능을 하나의 메서드로 추출하여 코드의 가독성과 재사용성을 높인다.
- 조건문 분해(Decompose Conditional) : 복잡한 조건문을 작은 블록으로 분해하여 코드의 가독성을 좋게 한다.
- 중복 제거(Remove Duplication) : 중복된 코드를 찾아 제거하고, 함수나 클래스로 추출하여 재사용성을 좋게 한다.
- 변수명 변경(Rename Variable) : 변수의 이름을 명확하게 변경하여 코드의 가독성을 좋게 한다.
- 상수 추출(Extract Constant) : 코드 내에서 자주 사용되는 상수를 변수나 상수로 추출하여 코드의 가독성을 좋게 한다.
- 함수 인라인(Inline Function) : 함수가 작고 중복이 없는 경우, 함수 호출 부분을 함수의 내용으로 대체하여 코드의 가독성을 좋게 한다.
- 매개변수 객체 만들기(Introduce Parameter Object) : 여러 개의 매개변수가 필요한 경우, 관련된 매개변수를 하나의 객체로 묶어 코드의 가독성을 좋게 한다.
- 클래스 추출(Extract Class) : 코드 블록에서 관련된 기능을 수행하는 코드를 클래스로 추출하여 코드의 구조를 개선한다.
이 외에도 많은 리팩터링 기법이 존재하며 적절한 리팩터링 기법을 선택하여 코드의 가독성 및 유지 보수성을 개선해야 한다.
⚡리팩터링을 수행하는 시점
- 코드 리뷰: 코드 리뷰를 통해 코드의 가독성, 유지보수성, 재사용성 등의 문제점을 발견했을 때 리팩터링을 수행한다.
- 버그 수정: 버그를 수정하기 위해 코드를 변경해야 할 때, 해당 코드를 리팩터링 하여 코드의 가독성과 유지보수성을 개선한다.
- 새로운 기능 추가: 새로운 기능을 추가하기 전에, 기존의 코드를 리팩터링 하여 코드의 가독성과 유지보수성을 개선한다.
- 코드 변경 시점: 코드 변경이 필요한 시점에 리팩터링을 수행합니다. 예를 들어, 코드의 중복을 제거하거나 코드의 구조를 단순화해야 할 때 리팩터링을 수행한다.
- 프로젝트 초기 단계: 프로젝트 초기 단계에서 리팩터링을 수행하여 초기 코드의 품질을 높인다.
위에 써놓은 시점 외에도 삼진 규칙(3번의 중복 / 3번의 같은 행위)을 하고 있다면 리팩터링을 수행해야 한다.
⚡나의 생각
리팩터링을 직접 하면서 느낀점을 적어 보려고 한다. 소스 구조 자체를 다이내믹하게 바꾸거나 하지 않더라도 한번 짜놓은 소스를 이해하기 쉽고 좀 더 효율적으로 동작하도록 개선되도록 작업하는 과정을 나는 리팩터링이라고 생각을 한다. 리팩터링은 반복적으로 수행되어야 하며, 코드 변경을 통해서 개선되는 부분이 존재하는 경우에 해야 한다.
회사에서도 다른 개발자들과 협업을 하면서 코드 리뷰를 할 때가 있고, 부끄럽지만 소스를 공유하면서 문제점을 찾고 개선하고 있다. 이 과정에서 많은 지식과 공부를 통해서 더욱더 성장하는 과정이 되고 있다. 분명 귀찮은 일이지만 개발자라면 리팩터링은 평생을 해야 한다고 생각을 하고 "이왕 할 거면 잘하자"라는 생각을 가지고 개발을 하고 있다.
다음에는 회사 내에서 소스 리팩토링을 했던 것 중에 기억에 남는 부분에 대해서 정리를 해보려고 한다.
