싸구려 코드를 쓰지 말고 싸게 하세요.

본고의 예는 자바로 작성되었지만 디스플레이 모델은 매우 기본적이며 대부분의 기본적인 대상과 기능 지원을 가진 언어에서 사용할 수 있다.
대부분의 경험이 풍부한 개발자들에게도 처음부터 코드를 작성하는 것은 어려운 일이다.여전히 이해하기 쉽고 변경하기 쉽고 테스트하기 쉽고 관찰할 수 있으며 전체 프로젝트의 생명 주기 내에 과도한 코드 중복이 없는 방식으로 기존 코드 라이브러리를 진화시키는 것은 여러 개발자와 단체가 처리해야 할 임무이다. 소수의 개발자와 팀은 이 임무를 성공적으로 완성했다.
거석은 타고난 것이 아니다Big Ball of Mud.그것들은 통상적으로 테스트할 수 있는 그럴듯한 층구조를 가지고 있어 몇 안 되는 개발자들이 그들의 일을 할 수 있을 정도로 발전하기 쉬우며 업무 수요를 효과적으로 해결했다.
이 글의 제목에 관해서 나는 이미 몇 차례 질문을 받았다.당신은 어떻게 시간을 뛰어넘어 저렴한 코드를 작성합니까?변경하기 쉬운 좋은 코드를 어떻게 만드는지에 대해서는 아직 매뉴얼이 없지만, 저는 저렴한 코드의 특징을 발견했습니다. 여러분과 공유하고 싶습니다.
우선, 코드를 변경하기 어려운 원인을 예시와 원인을 통해 분석합시다.

공유 인프라 코드 변경이 어렵습니다.

공유 코드는 일종의 약속이다.당신은 서로 다른 기능과 수요를 하나의 단일한 핫이슈로 모아 실제 논리를 실현할 수 있습니다.이러한 모델의 좋은 예는 기본 클래스와 실용 함수입니다.

이로 인해 AbstractDAO는 변경하기 어렵다. 왜냐하면 이것은 상관없을 수 있는 세 가지 영역에 영향을 주고 여러 가지 특성에 영향을 줄 수 있기 때문이다.
이 문제를 피하기 위해서는 세 가지 선택이 있다.

공유 코드를 사용하는 프레임워크에 의뢰합니다.

기초 구조 코드와 코드 라이브러리를 결합시켜 위에서 사용자 정의 프레임워크를 구축합니다.

코드를 복사했습니다.

가장 싼 선택은 첫 번째, 프레임워크에 권한을 부여하는 것이다.프레임워크는 이미 가장 흔히 볼 수 있는 문제에 해결 방안을 제공했다. 당신은 독특한 문제에 직면할 가능성이 매우 낮다.가능하다면 인프라를 의뢰하는 틀입니다.
다음 가장 싼 선택은 코드 복제다.중복된 코드가 상대적으로 시끄러워도 여러 위치에서 똑같은 코드를 가지고 있을 가능성은 낮다.너무 빠른 코드 재사용은 해결 방안이 너무 일찍 범용될 가능성을 증가시켜 코드가 업무에 전념하지 못하게 한다.앞으로 업무 언어를 말하지 않는 코드는 업무 학습에 사용하기도 어렵고 변경하기도 어렵다.
이 밖에 코드 복제는 서비스의 가용성을 높이는 데 도움이 된다.핫스팟을 피하면 핫스팟에 의존하는 모든 종류(메모리 유출, 연결 탱크 유출과 관련)에 영향을 미치는 일련의 고장 가능성을 낮출 수 있다.

공유 도메인 코드 변경이 어렵습니다.

첫 번째와 관련된 것은 역 코드도 변경하기 어렵다는 것이다.
프로젝트가 시작되었을 때, 모든 것이 때가 낀 것처럼 보였다.몇 개의 텍스트 상자, 드롭다운 목록, 제출 단추만 있으면 삽입할 수 있습니다.잠시 후, 제출 항목의 목록, 심지어 그것들의 상세한 정보를 보길 원할 것입니다.
조심하다시간의 추이에 따라 업무 규칙은 갈수록 복잡해진다. 오늘은 마치 때가 낀 것처럼 보이고 몇 달 후에는 완전히 달라질 것이다.아마도 이것은 하나의 단추일 것이다. 이것은 자동으로 모든 것을 완성할 수 있다. o는 복잡한 사용자 여정이 되고 서로 다른 제3자 서비스에서 서로 다른 정보를 채울 수 있다.
공유역 코드를 피하고 추상적인 실체를 피하며 가치 대상의 조합을 지원한다.예를 들어, 이러한 Java 클래스를 살펴보겠습니다.

public abstract class BaseBook {
    private long bookId;
    private String bookTitle;
    private String authorName;
    private BigDecimal price;
    private BigDecimal salesPrice;

    ...constructor
}

public class Book extends BaseBook {
    private long stock;
    private long warehouse;
}

논리와 속성을 공유하기 위해 BaseBook을 확장하는 것은 안전해 보이지만, 기본 클래스가 증가할 때 Book은 확장하기 어렵고, BaseBook은 변경하기 어렵다.그 밖에 속성의 경계와 그것들 간의 관계를 모호하게 했다.대신 경계를 명확하게 하기 때문에 값 대상입니다.

public final class Cover { 
    private final String bookTitle;
    private final String bookName;

    ...constructor
}

public final class Author {
    private final String authorName;

    ...constructor
}

public final class Price {
    private final BigDecimal original;
    private final BigDecimal sales;

    ...constructor
}

public final class Stock {
    private final long quantity;
    private final long warehouse;

    ...constructor
}

public class Book {
    private final long bookId;
    private Cover cover;
    private Author author;
    private Price price;
    private Stock stock;

    ...constructor
}

값 대상을 둘러싼 분리 지식은 코드를 장기적으로 이해하기 쉽고 값 대상을 기본 클래스보다 변경하는 것이 쉽다. 왜냐하면 그들은 스스로 포함하기 때문이다.

선풍기 관계 피하기

클래스 간의 부채질 관계는 한 클래스가 다른 더 많은 클래스에 직접적이거나 간접적으로 의존할 때의 상황을 가리킨다.예를 들어, 동일한 도메인 객체를 사용하는 여러 기능이 있습니다.예제 그림은 다음과 같습니다.

이런 상황이 발생했을 때, 당신은 자신에게 다음과 같은 스트레칭 문제를 물어야 한다.

이나 그들의 행동에 대한 데이터가 필요합니까?
만약 답이 데이터일 뿐이라면, 값 대상만 사용하거나 전체 실체가 아닌 새로운 읽기 모델을 정의하는 것을 고려하십시오.SQL 데이터베이스가 있는 경우 뷰의 결과만 공유할 수 있습니다.단일 보기를 이동하는 것은 코드의 10여 개의 점에서 사용하는 클래스를 변경하는 것보다 훨씬 쉽다.

모든 곳Book의 동일한 데이터나 행위가 필요합니까?
만약 답이 부정적이라면, 새로운 읽기 모델을 정의해야 한다.만약 데이터와 행위가 모두 다르다면, 우리가 이야기하는 것은 서로 다른 유계 상하문/제품일 것이다.

저는 그냥 책을 보고 있는 건가요?아니면 글쓰기?
만약 당신이 글을 쓰고 행동이 다르다면, 당신은 서로 다른 유계어경/제품에 처해 있을 것이다.코드 분리를 유지하다.만약 네가 단지 책을 읽고 있을 뿐이라면, 읽기 모형 하나면 충분하다.

그러나 우리는 코드의 경계가 명확하고 다른 방식으로 쉽게 추출하고 교체할 수 있도록 도구를 사용할 수 있다.

제품 기반의 선형 차원 구조 지원

병렬 차원 구조 (Book 를 변경하는 것은 매우 어렵다. 왜냐하면 그들은 일반적으로 데이터 (UserController, UserService, User, UserRepository) 를 바탕으로 정의되기 때문에 다른 서비스에서 공유되기 때문이다.이러한 관계를 정의하지 않고 제품 기반 계층 구조를 정의할 수 있습니다.XController, XService, X, XRepository,OneClickPurchase,StandardPurchase,SearchPage,Newsletter은 업무 차원에서 더욱 표현력을 가지며 경계를 더욱 잘 정의한다.

값 대상에 기반한 편평한 차원 구조 지원

계승이 틀린 것은 아니지만 만약에 우리가 정확한 추리가 없는 상황에서 그것을 사용한다면 결합의 이슈가 될 수 있다. 값 대상의 조합에 유리하고 코드를 재구성하고 추출하기 쉬우며 추상적인 클래스에 비해 테스트 값 대상이 상대적으로 쉽다.

피쳐 전환으로 경계 정의하기

코드를 비활성화할 수 있다면, 코드를 추출할 수 있습니다.언제든지 비활성화할 수 있는 피쳐 전환을 사용하여 경계를 정의합니다.이것은 또한 당신의 코드를 더욱 신뢰할 수 있게 하기 때문에 사건이 발생할 때 언제든지 제품이나 기능을 비활성화할 수 있습니다.기능 전환의 예는 다음과 같습니다.

public final class StandardPurchase {
    private final StandardPurchaseContext context;
    private final DeliveryInformation delivery;
    private final FeatureToggle toggle;

    ...constructor

    public PurchaseSummary summary(User forUser) {
        PurchaseSummary summary = context.summary(forUser);

        if (toggle.enabled(ONE_DAY_DELIVERY)) {
            OneDayDeliveryForecast forecast = delivery.oneDayDelivery(forUser);
            return summary.oneDayDelivery(forecast);
        }

        return summary;
    }
}

가능하다면 테스트 기간에 시뮬레이션을 다시 고려하십시오

기본적으로 의존 항목을 시뮬레이션하면 테스트 시간이 빨라집니다.그러나 이것은 코드의 경계를 모호하게 할 수도 있다. 왜냐하면 아날로그 외부 의존 관계가 상대적으로 싸기 때문이다.
만약 통합 테스트가 매우 비싸다면, 나중에 테스트 중인 코드를 쉽게 추출하거나 변경할 수 있도록 대량의 클래스에 의존해야 할 수도 있습니다.