Java에서 리팩토링이 작동하는 방식

프로그래밍을 배울 때 코드를 작성하는 데 많은 시간이 소요됩니다. 대부분의 초보 개발자는 이것이 미래의 활동이라고 믿습니다. 이는 부분적으로 사실이지만 프로그래머의 작업에는 코드 유지 관리 및 리팩토링도 포함됩니다. 오늘은 리팩토링에 대해 이야기하겠습니다.

JavaRush 과정의 리팩토링

JavaRush 과정에서는 리팩토링 주제를 두 번 다룹니다.

• 멀티스레딩 퀘스트 레벨 5에 대한 큰 도전입니다 .
• Java 컬렉션 퀘스트 레벨 9에서 Intellij IDEA의 리팩토링에 대한 강의입니다 .

큰 작업 덕분에 실제 리팩토링을 실제로 접할 수 있는 기회가 있으며, IDEA의 리팩토링 강의는 삶을 놀라울 정도로 쉽게 만들어주는 자동 도구를 이해하는 데 도움이 될 것입니다.

리팩토링이란 무엇입니까?

이는 기능을 변경하지 않고 코드 구조를 변경하는 것입니다. 예를 들어, 두 숫자를 비교하여 첫 번째 숫자가 더 크면 true를 반환하고 그렇지 않으면 false를 반환하는 메서드가 있습니다 .

public boolean max(int a, int b) {
    if(a > b) {
        return true;
    } else if(a == b) {
        return false;
    } else {
        return false;
    }
}

결과는 매우 번거로운 코드였습니다. 초보자라도 이런 글을 쓰는 경우는 거의 없는데 이런 위험이 있습니다. if-else메소드를 6줄 더 짧게 작성할 수 있다면 왜 여기에 블록이 있는 것 같습니다 .

public boolean max(int a, int b) {
     return a>b;
}

이제 이 방법은 위의 예와 동일한 작업을 수행하지만 간단하고 우아해 보입니다. 이것이 리팩토링이 작동하는 방식입니다. 코드의 본질에 영향을 주지 않고 코드의 구조를 변경합니다. 리팩토링 방법과 기술에는 여러 가지가 있으며 이에 대해 더 자세히 살펴보겠습니다.

리팩토링이 필요한 이유는 무엇입니까?

몇 가지 이유가 있습니다. 예를 들어, 코드의 단순성과 간결성을 추구합니다. 이 이론을 지지하는 사람들은 비록 코드를 이해하려면 수십 줄의 주석이 필요하더라도 코드는 최대한 간결해야 한다고 믿습니다. 다른 개발자들은 최소한의 주석으로 코드를 이해할 수 있도록 리팩터링해야 한다고 믿습니다. 각 팀은 자신의 위치를 ​​선택하지만 리팩토링은 축소가 아니라는 점을 기억해야 합니다 . 주요 목표는 코드 구조를 개선하는 것입니다. 이 글로벌 목표에는 여러 가지 목표가 포함될 수 있습니다.

1. 리팩토링은 다른 개발자가 작성한 코드에 대한 이해를 향상시킵니다.
2. 오류를 찾고 수정하는 데 도움이 됩니다.
3. 소프트웨어 개발 속도를 높일 수 있습니다.
4. 전반적으로 소프트웨어 구성이 향상됩니다.

오랫동안 리팩토링을 수행하지 않으면 개발에 어려움을 겪을 수 있으며, 작업이 완전히 중단될 수도 있습니다.

“코드 냄새”

코드에 리팩토링이 필요할 때 그들은 "냄새가 난다"고 말합니다. 물론 문자 그대로 그런 것은 아니지만 이러한 코드는 실제로는 별로 좋아 보이지 않습니다. 아래에서는 초기 단계의 주요 리팩토링 기술을 살펴보겠습니다.

불필요하게 큰 요소

크기가 크기 때문에 효율적으로 정확하게 작업하는 것이 불가능한 성가신 클래스와 메서드가 있습니다.

큰 수업

이러한 클래스에는 엄청난 수의 코드 줄과 다양한 메서드가 있습니다. 일반적으로 개발자는 새 클래스를 만드는 것보다 기존 클래스에 기능을 추가하는 것이 더 쉽기 때문에 클래스가 성장합니다. 일반적으로 이 클래스의 기능은 오버로드됩니다. 이 경우 기능의 일부를 별도의 클래스로 분리하는 것이 도움이 됩니다. 이에 대해서는 리팩토링 기술 섹션에서 더 자세히 설명하겠습니다.

큰 방법

이 "냄새"는 개발자가 메서드에 새로운 기능을 추가할 때 발생합니다. “여기에 쓸 수 있는데 왜 매개변수 검사를 별도의 메소드에 넣어야 할까요?”, “배열에서 최대 요소를 찾는 메소드를 왜 분리해야 하는지, 여기에 남겨두겠습니다. 이렇게 하면 코드가 더 명확해집니다.” 등의 오해도 있습니다. 대규모 메서드를 리팩터링하는 데는 두 가지 규칙이 있습니다.

1. 메소드를 작성할 때 코드에 주석을 추가하려면 이 기능을 별도의 메소드로 분리해야 합니다.
2. 메서드에 10~15줄 이상의 코드가 필요한 경우 해당 메서드가 수행하는 작업과 하위 작업을 식별하고 하위 작업을 별도의 메서드로 분리해야 합니다.

대규모 메서드를 제거하는 여러 가지 방법:

• 메소드 기능의 일부를 별도의 메소드로 분리합니다.
• 지역 변수를 사용하여 기능의 일부를 추출할 수 없는 경우 전체 개체를 다른 메서드에 전달할 수 있습니다.

다양한 기본 데이터 유형 사용

일반적으로 이 문제는 클래스에 데이터를 저장하는 필드 수가 시간이 지남에 따라 증가할 때 발생합니다. 예를 들어 작은 객체 대신 기본 유형을 사용하여 데이터(통화, 날짜, 전화번호 등)를 저장하거나 상수를 사용하여 정보를 인코딩하는 경우입니다. 이 경우 좋은 방법은 필드를 논리적으로 그룹화하고 별도의 클래스에 배치하는 것입니다(클래스 선택). 클래스에 이 데이터를 처리하기 위한 메서드를 포함할 수도 있습니다.

긴 옵션 목록

특히 대규모 방법과 결합할 때 상당히 흔한 실수입니다. 이는 일반적으로 메서드의 기능이 오버로드되거나 메서드가 여러 알고리즘을 결합하는 경우 발생합니다. 매개변수의 긴 목록은 이해하기 매우 어려우며 이러한 방법은 사용하기 불편합니다. 따라서 전체 개체를 전송하는 것이 좋습니다. 개체에 데이터가 충분하지 않은 경우 보다 일반적인 개체를 사용하거나 메서드의 기능을 분할하여 논리적으로 관련된 데이터를 처리하는 것이 좋습니다.

데이터 그룹

논리적으로 관련된 데이터 그룹이 코드에 나타나는 경우가 많습니다. 예를 들어 데이터베이스에 대한 연결 매개변수(URL, 사용자 이름, 비밀번호, 스키마 이름 등)입니다. 요소 목록에서 단일 필드를 제거할 수 없는 경우 목록은 별도의 클래스(클래스 선택)에 배치되어야 하는 데이터 그룹입니다.

OOP 개념을 망치는 솔루션

이러한 유형의 "냄새"는 개발자가 OOP 설계를 위반할 때 발생합니다. 이는 그가 이 패러다임의 기능을 완전히 이해하지 못하고 이를 불완전하거나 부정확하게 사용하는 경우에 발생합니다.

상속 거부

하위 클래스가 상위 클래스의 기능 중 최소한의 부분을 사용하면 잘못된 계층 구조의 냄새가 납니다. 일반적으로 이 경우 불필요한 메서드는 재정의되지 않거나 예외가 발생합니다. 클래스가 다른 클래스에서 상속된다면 이는 해당 기능을 거의 완벽하게 사용한다는 의미입니다. 올바른 계층 구조의 예: 잘못된 계층 구조의 예:

스위치 문

운영자에게 무슨 문제가 있을 수 있나요 switch? 디자인이 매우 복잡하면 좋지 않습니다. 여기에는 많은 중첩 블록도 포함됩니다 if.

다양한 인터페이스를 갖춘 대체 클래스

여러 클래스가 실제로 동일한 작업을 수행하지만 해당 메서드의 이름은 다릅니다.

임시 필드

클래스에 객체에 가끔씩만 필요한 임시 필드가 포함되어 있고 값으로 채워지고 나머지 시간은 비어 있거나 금지되어 있는 경우 코드에서 " null냄새가 나며" 그러한 디자인은 모호합니다. 결정.

수정을 어렵게 만드는 냄새

이러한 "냄새"는 더 심각합니다. 나머지는 주로 코드 이해를 방해하지만 코드 수정을 불가능하게 합니다. 어떤 기능을 도입하면 개발자 중 절반은 그만두고 절반은 미쳐버릴 것입니다.

병렬 상속 계층

클래스의 하위 클래스를 생성할 때 다른 클래스의 또 다른 하위 클래스를 생성해야 합니다.

균일한 종속성 분포

수정을 수행할 때 이 클래스의 모든 종속성(사용)을 찾아 작은 변경 사항을 많이 적용해야 합니다. 한 번의 변경 - 여러 수업에서 수정됩니다.

복잡한 수정 트리

이 냄새는 이전 냄새와 반대입니다. 변경 사항은 동일한 클래스의 많은 메서드에 영향을 미칩니다. 일반적으로 이러한 코드의 종속성은 연속적입니다. 한 메소드를 변경한 후 다른 메소드에서 수정해야 하고 세 번째 메소드에서 수정해야 하는 식입니다. 하나의 수업 - 많은 변화.

“쓰레기 냄새”

두통을 유발하는 다소 불쾌한 냄새 카테고리입니다. 쓸모없고 불필요하며 오래된 코드입니다. 다행스럽게도 최신 IDE와 린터는 이러한 냄새에 대해 경고하는 방법을 배웠습니다.

메소드에 많은 댓글이 있음

이 메서드에는 거의 모든 줄에 많은 설명 주석이 있습니다. 이는 일반적으로 복잡한 알고리즘과 연관되어 있으므로 코드를 여러 개의 작은 메소드로 나누고 의미 있는 이름을 지정하는 것이 좋습니다.

코드 복제

서로 다른 클래스나 메서드는 동일한 코드 블록을 사용합니다.

게으른 수업

많은 기능이 계획되었지만 수업은 거의 기능을 사용하지 않습니다.

사용되지 않은 코드

클래스, 메소드 또는 변수는 코드에서 사용되지 않으며 "죽은 무게"입니다.

과도한 결합

이 냄새 범주는 코드에 불필요한 연결이 많다는 특징이 있습니다.

타사 방법

메서드는 자체 데이터를 사용하는 것보다 다른 개체의 데이터를 훨씬 더 자주 사용합니다.

부적절한 친밀감

클래스는 다른 클래스의 서비스 필드와 메소드를 사용합니다.

긴 수업 통화

한 클래스는 다른 클래스를 호출하여 세 번째, 네 번째 등의 데이터를 요청합니다. 이렇게 긴 호출 체인은 현재 클래스 구조에 대한 의존도가 높다는 것을 의미합니다.

클래스 작업 딜러

클래스는 다른 클래스에 작업을 전달하는 데에만 필요합니다. 어쩌면 제거해야할까요?

리팩토링 기법

아래에서는 설명된 코드 냄새를 제거하는 데 도움이 되는 초기 리팩토링 기술에 대해 설명합니다.

클래스 선택

클래스가 수행하는 기능이 너무 많아 그 중 일부를 다른 클래스로 이동해야 합니다. 예를 들어, 거주지 주소도 포함하는 클래스 Human와 전체 주소를 제공하는 메서드가 있습니다.

class Human {
   private String name;
   private String age;
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

주소 정보와 방법(데이터 처리 동작)을 별도의 클래스에 배치하는 것이 좋습니다.

class Human {
   private String name;
   private String age;
   private Address address;

   private String getFullAddress() {
       return address.getFullAddress();
   }
}
class Address {
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

방법 선택

기능을 하나의 메소드로 그룹화할 수 있는 경우 별도의 메소드에 배치해야 합니다. 예를 들어, 이차 방정식의 근을 계산하는 방법은 다음과 같습니다.

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        double x1, x2;
        x1 = (-b - Math.sqrt(D)) / (2 * a);
        x2 = (-b + Math.sqrt(D)) / (2 * a);
        System.out.println("x1 = " + x1 + ", x2 = " + x2);
    }
    else if (D == 0) {
        double x;
        x = -b / (2 * a);
        System.out.println("x = " + x);
    }
    else {
        System.out.println("Equation has no roots");
    }
}

가능한 세 가지 옵션 모두의 계산을 별도의 방법으로 옮겨 보겠습니다.

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        dGreaterThanZero(a, b, D);
    }
    else if (D == 0) {
        dEqualsZero(a, b);
    }
    else {
        dLessThanZero();
    }
}

public void dGreaterThanZero(double a, double b, double D) {
    double x1, x2;
    x1 = (-b - Math.sqrt(D)) / (2 * a);
    x2 = (-b + Math.sqrt(D)) / (2 * a);
    System.out.println("x1 = " + x1 + ", x2 = " + x2);
}

public void dEqualsZero(double a, double b) {
    double x;
    x = -b / (2 * a);
    System.out.println("x = " + x);
}

public void dLessThanZero() {
    System.out.println("Equation has no roots");
}

각 메소드의 코드는 훨씬 더 짧고 명확해졌습니다.

전체 개체 전송

매개변수를 사용하여 메서드를 호출할 때 다음과 같은 코드를 볼 수 있는 경우가 있습니다.

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double yearlySalary = employee.getYearlySalary();
    double awards = employee.getAwards();
    double monthlySalary = getMonthlySalary(yearlySalary, awards);
    // Продолжение обработки
}

public double getMonthlySalary(double yearlySalary, double awards) {
     return (yearlySalary + awards)/12;
}

이 방법에서는 employeeMethod값을 얻고 이를 기본 변수에 저장하기 위해 최대 2줄이 할당됩니다. 때로는 이러한 디자인에 최대 10줄이 소요되기도 합니다. 필요한 데이터를 추출할 수 있는 메소드에 객체 자체를 전달하는 것이 훨씬 쉽습니다.

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double monthlySalary = getMonthlySalary(employee);
    // Продолжение обработки
}

public double getMonthlySalary(Employee employee) {
    return (employee.getYearlySalary() + employee.getAwards())/12;
}

간단하고 짧고 간결합니다.

필드를 논리적으로 그룹화하고 별도의 클래스에 배치

위의 예는 매우 간단하고 이를 볼 때 많은 개발자가 "실제로 이 작업을 수행하는 사람은 누구입니까?"라는 질문을 할 수 있음에도 불구하고 많은 개발자는 부주의, 코드 리팩토링에 대한 의지 또는 단순히 "할 것입니다"로 인해 비슷한 구조적 오류.

리팩토링이 효과적인 이유

좋은 리팩토링의 결과는 코드가 읽기 쉽고, 프로그램 로직의 수정이 위협이 되지 않으며, 새로운 기능의 도입이 코드 파싱 지옥으로 바뀌지 않고 며칠 동안 즐거운 활동을 할 수 있는 프로그램입니다. . 프로그램을 처음부터 다시 작성하는 것이 더 쉽다면 리팩토링을 사용해서는 안 됩니다. 예를 들어, 팀에서는 동일한 기능을 처음부터 구현하는 것보다 코드를 구문 분석, 분석 및 리팩토링하는 데 드는 인건비가 더 높을 것으로 추정합니다. 또는 리팩토링이 필요한 코드에는 디버깅하기 어려운 오류가 많이 있습니다. 프로그래머의 작업에서는 코드 구조를 개선하는 방법을 아는 것이 필수입니다. 연습에 중점을 둔 온라인 코스인 JavaRush에서 Java 프로그래밍을 배우는 것이 더 좋습니다. 즉각적인 검증이 가능한 1200개 이상의 작업, 약 20개의 미니 프로젝트, 게임 작업 - 이 모든 것이 코딩에 자신감을 갖는 데 도움이 됩니다. 지금이 시작하기에 가장 좋은 시기입니다 :)

리팩토링에 대한 추가 연구를 위한 리소스

리팩토링에 관한 가장 유명한 책은 『리팩토링』이다. 기존 코드의 디자인 개선”(Martin Fowler 저). Joshua Kiriewski가 쓴 이전 책인 "Refactoring with Patterns"를 기반으로 작성된 리팩토링에 관한 흥미로운 출판물도 있습니다. 템플릿에 대해 말하면. 리팩토링할 때 기본 애플리케이션 디자인 패턴을 아는 것은 항상 매우 유용합니다. 다음의 훌륭한 책들이 도움이 될 것입니다:

1. "디자인 패턴" - Head First 시리즈의 Eric Freeman, Elizabeth Freeman, Kathy Sierra, Bert Bates 제작;
2. "읽기 쉬운 코드 또는 예술로서의 프로그래밍" - Dustin Boswell, Trevor Faucher.
3. 아름답고 우아한 코드의 원칙을 설명하는 Steve McConnell의 "Perfect Code".

리팩토링에 관한 몇 가지 기사:

1. 정말 힘든 일입니다. 레거시 코드 리팩토링을 시작해 보겠습니다 .
2. 리팩토링 ;
3. 모두를 위한 리팩토링 .