패러다임 변경: 성급한 리팩토링과 허위 '재사용성'에서 적응성, 확장성 및 안정성으로

소프트웨어 세계에는 조기 리팩토링에 대한 집착과 가짜 재사용성 추구이 만연합니다. 개발자, 특히 처음 시작하는 개발자는 종종 "재사용성"이 성배라고 배웁니다. 그러나 어떤 희생을 치르더라도 재사용성을 추구하다 보면 너무 일반적이고, 너무 경직되며, 현재 프로젝트의 특정 요구 사항과 너무 동떨어진 과도한 엔지니어링 솔루션이 탄생하는 경우가 많습니다. 실제로 이는 우리가 흔히 "추상화 지옥"이라고 부르는 상황으로 이어질 수 있습니다. 시스템의 모든 부분이 일반 인터페이스에 맞게 추상화되는 방법과 이유를 완전히 이해하지 않으면 실제로 아무것도 작동하지 않는 시나리오입니다.

패러다임 전환을 제안합니다. 재사용성에 집착하기보다는 적응성, 확장성, 재정의성에 집중합시다.

이러한 맥락에서 우리는 코드베이스의 미래 요구 사항을 예측하는 것(미래를 예측하는 점쟁이처럼)에서 벗어나 여전히 성장할 여지가 있고 미래가 펼쳐지면서 진화하세요.

---

조기 리팩토링 딜레마: 가짜 재사용성

조기 리팩토링의 문제는 작성하는 모든 것이 재사용 가능해야 한다는 믿음에서 비롯된다는 것입니다. 이것은 고귀한 목표처럼 보일 수도 있습니다. 그러나 재사용성은 불필요한 복잡성과 불필요한 추상화를 초래하는 경우가 많습니다. 예를 들어, 모든 모델에 작동하는 범용 API 어댑터를 생성한다는 개념을 생각해 보세요. 이상적인 것은 이 어댑터가 모든 API 엔드포인트, 데이터 형식 및 네트워크 조건을 처리할 수 있다는 것입니다. 그러나 실제로 이는 오늘날의 문제를 효과적으로 해결하는 것이 아니라 불확실한 미래를 위한 프레임워크를 구축하고 있음을 의미합니다.

예:

이전의 BaseAdapter 및 APIAdapter 클래스를 살펴보겠습니다.

export class BaseAdapter {
    constructor(modelClass) {
        this.modelClass = modelClass;
    }

    async get(id) {
        throw new Error("Method 'get' must be implemented.");
    }

    async *all() {
        throw new Error("Method 'all' must be implemented.");
    }

    async query(params = {}) {
        throw new Error("Method 'query' must be implemented.");
    }

    async create(payload) {
        throw new Error("Method 'create' must be implemented.");
    }

    async update(payload) {
        throw new Error("Method 'update' must be implemented.");
    }

    async delete(id) {
        throw new Error("Method 'delete' must be implemented.");
    }
}

위 코드에서 BaseAdapter는 가능한 모든 메서드를 정의하므로 이를 특정 하위 클래스(예: APIAdapter, LocalStorageAdapter 등)에 구현할 수 있습니다. 각종 어댑터에 대한 템플릿입니다. 이론상으로는 좋은 것 같죠? 언젠가 새로운 서비스에 연결하거나 새로운 스토리지 솔루션과 통합해야 하는 경우 다른 하위 클래스를 생성하면 됩니다.

하지만 현실로 돌아가 보겠습니다. 정말 재사용이 가능할까요? 아니면 시스템이 복잡해져서 유지 관리, 이해, 확장이 더 어려워질까요? 정말 실제세계에서 재사용할 수 있는 무언가를 만들고 있나요, 아니면 단지 미래에 대해 추측하고 있나요?

---

변화: 재사용성에서 적응성, 확장성, 재정의성으로

성급한 재사용성을 추구하기보다는 적응성과 확장성에 중점을 둘 것을 제안합니다. 그게 무슨 뜻인가요?

1. 적응성: 많은 부분의 코드를 다시 작성하지 않고도 쉽게 변경하거나 확장할 수 있는 기반을 만듭니다.
2. 확장성: 전체 아키텍처를 리팩터링할 필요 없이 새로운 기능을 위한 여지를 남겨두세요.
3. 재정의 가능성: 모든 것을 손상시킬 위험 없이 다른 사람(또는 미래에는 자신)이 코드를 쉽게 확장하거나 재정의할 수 있습니다.

이것은 오늘날 모든 극단적인 경우에 작동하는 완벽하게 재사용 가능한 코드를 만드는 것이 아닙니다. 대신 시간이 지남에 따라 구축하고, 추가하고, 수정할 수 있는 단단한 기반을 구축하는 데 중점을 둡니다. 핵심은 성급한 최적화가 아닌 유연성입니다.

---

오래된 "인터페이스" 패러다임: 미래 예측

Java(및 기타 많은 정적 유형 언어)의 예전에는 인터페이스를 만들고 코드를 '미래에도 사용할 수 있도록' 만드는 데 중점을 두는 경우가 많았습니다. 모든 시나리오를 미리 예측하고 이를 중심으로 설계하는 것이 아이디어였습니다.

그러나 이러한 접근 방식은 종종 과도한 엔지니어링을 초래할 수 있습니다. 즉, 결코 일어나지 않을 일을 설계하거나 아직 표면화되지 않은 문제에 대해 추상적인 프레임워크를 구축하는 것입니다. 작업 중인 시스템의 구체적인 요구 사항을 이해하지 못한 채 "보편적"이어야 하는 코드를 효과적으로 작성하고 있습니다.

Java에서는 인터페이스를 사용하여 계약을 정의했습니다. 하지만 이러한 생각을 '계약 정의'에서 단순히 현재에 대한 기대 설정으로 바꾸면 어떨까요? 미래에 일어날 일을 가정하지 않고 즉각적인 상황에 명확하고 신뢰할 수 있는 약속입니다.

---

새로운 종류의 약속: 미래의 자신에 대한 약속

우리의 새로운 접근 방식에서는 신비로운 점쟁이처럼 애플리케이션의 미래에 대해 약속하지 않습니다. 대신, 우리는 현재에 대한 명확하고 신뢰할 수 있는 약속을 설정하고, 필요할 때 이러한 약속을 쉽게 확장하고 조정할 수 있도록 합니다.

이렇게 생각해 보세요. 우리는 5년 후 세상이 어떤 모습일지 예측하는 것이 아닙니다. 우리는 오늘날 우리가 작성하는 코드가 세상의 변화에 ​​따라 진화하고 적응할 수 있도록 보장하고 있습니다. 이는 건물의 기초를 튼튼하게 하여 어떠한 변화에도 견딜 수 있을 만큼 견고한지 확인하는 것과 같습니다.

우리가 하는 "약속"은 적응성과 확장성에 대한 약속입니다. 목표는 미래를 예측하는 것이 아니라 미래의 개발자(또는 미래의 자신)가 필요에 따라 기능을 쉽게 추가, 수정 또는 확장할 수 있는 도구를 만드는 것입니다.

---

실제 예: 어댑터 확장 및 재정의

BaseAdapter 및 APIAdapter를 사용한 예시를 다시 살펴보겠습니다. 모든 상황을 처리하려고 시도하는 매우 일반적인 메소드를 만드는 대신 적응 가능하고 쉽게 확장 가능한 코드를 만드는 데 중점을 둘 것입니다.

APIAdapter의 간단한 재구성은 다음과 같습니다.

export class BaseAdapter {
    constructor(modelClass) {
        this.modelClass = modelClass;
    }

    async get(id) {
        throw new Error("Method 'get' must be implemented.");
    }

    async *all() {
        throw new Error("Method 'all' must be implemented.");
    }

    async query(params = {}) {
        throw new Error("Method 'query' must be implemented.");
    }

    async create(payload) {
        throw new Error("Method 'create' must be implemented.");
    }

    async update(payload) {
        throw new Error("Method 'update' must be implemented.");
    }

    async delete(id) {
        throw new Error("Method 'delete' must be implemented.");
    }
}

이제 모든 새로운 유형의 어댑터에 대해 완전히 새로운 BaseAdapter를 만드는 대신 향후 요구 사항에 맞게 쉽게 확장하고 조정할 수 있는 기반을 만들었습니다.

새 API 엔드포인트 확장의 예:

export class APIAdapter extends BaseAdapter {
    static baseURL;
    static headers;
    static endpoint;

    async *all(params = {}) {
        // Custom logic, but easily extensible if needed
        const url = `${this.baseURL}/${this.endpoint}`;
        const response = await API.get(url, { params, headers: this.headers });
        return response.data;
    }

    async query(params = {}) {
        // Simplified for illustration
        const url = `${this.baseURL}/${this.endpoint}/search`;
        const response = await API.get(url, { params });
        return response.data;
    }

    // Easily extendable for specific cases
    async customRequest(method, endpoint, params = {}) {
        const url = `${this.baseURL}/${endpoint}`;
        const response = await API[method](url, { params });
        return response.data;
    }
}

이 시나리오에서 하나의 API 엔드포인트에 대한 특정 동작(예: 주문에 대한 사용자 정의 오류 처리)을 추가해야 하는 경우 APIAdapter를 재정의하거나 확장할 수 있습니다. 전체 시스템을 리팩토링하지 않고도 필요합니다.

---

결론: 미래의 자신에 대한 약속

이 새로운 패러다임에서는 미래의 모든 필요 사항이나 문제를 예측하려고 하지 않습니다. 대신 요구 사항이 변화하고 새로운 과제가 발생함에 따라 적응할 수 있는 강력하고 유연한 기반을 구축하는 데 중점을 둡니다. 우리는 성급하게 추상화하거나 가상의 문제를 기반으로 솔루션을 과도하게 설계하지 않습니다. 대신, 우리는 새로운 요구 사항이 발생할 때마다 발전하고 쉽게 적응할 수 있는 도구를 만듭니다.

핵심은 점쟁이처럼 미래를 보장하는 것이 아니라, 세상이 변하더라도 시간의 시험을 안정적으로 견딜 수 있는 기반을 만드는 것입니다. 다음은 미래의 자신에게 할 수 있는 약속입니다. 코드는 견고하고 적응성이 뛰어나며 새로운 요구 사항이 발생하면 확장할 준비가 되어 있습니다.

위 내용은 패러다임 변경: 성급한 리팩토링과 허위 '재사용성'에서 적응성, 확장성 및 안정성으로의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!