소프트웨어 개발의 세계에서 우리는 종종 명령형과 선언형이라는 두 가지 패러다임 사이에서 갈등을 겪습니다. 많은 개발자에게 명령형 코드의 매력은 단순성입니다. 지침을 단계별로 작성하기만 하면 컴퓨터가 수행하는 작업을 정확히 알 수 있습니다. 그러나 복잡성이 증가함에 따라 이러한 단계별 접근 방식은 코드베이스 전체에 흩어져 있는 뒤엉킨 논리의 혼란으로 변합니다. 이와 대조적으로 선언적 접근 방식은 원하는 것을 얻는 방법이 아니라 원하는 것을 설명할 수 있도록 하여 세부 사항을 세세하게 관리할 필요가 없도록 하는 것을 목표로 합니다.
이 게시물에서 우리는 선언적 접근 방식이 "최고"라는 것을 증명하기 위해 여기에 있는 것이 아닙니다. 대신, 선언적 설계를 통해 개발자의 지능을 존중하는 시스템을 구축하여 애플리케이션을 우아하게 성장시키고 훨씬 적은 인지적 오버헤드로 유지 관리할 수 있는 방법을 살펴보겠습니다.
다양한 API에서 게시물과 사용자를 가져오는 작은 애플리케이션을 구축한다고 상상해 보세요. 명령형 방식은 다음과 같습니다:
const axios = require('axios');
// Imperative approach: You write every step for every request
async function fetchAllPosts() {
const response = await axios.get('https://jsonplaceholder.typicode.com/posts');
return response.data;
}
async function fetchUsers() {
const response = await axios.get('https://dummyjson.com/users');
return response.data.users;
}
얼핏 보면 간단해 보입니다. GET 요청을 수행하고 데이터를 반환하기만 하면 됩니다. 하지만 복잡성이 커지면 어떻게 될까요? 다음이 필요할 수 있습니다:
곧 코드를 복사하여 붙여넣고, 엔드포인트와 헤더를 곳곳에 하드코딩하고, 복잡한 로직 웹을 수동으로 관리하게 될 것입니다. 명령형 스타일은 자질구레한 일처럼 느껴지기 시작합니다. 동일한 지침을 계속해서 작성하고 모든 논리가 어디에 있는지 잊어버리기 쉽습니다.
이제 좀 더 선언적인 디자인을 살펴보겠습니다. 시스템에 각 리소스를 가져오는 방법을 알려주는 대신 각 리소스의 어떤 모습, 어디에 있는지, 다른 리소스와 어떻게 관련되는지 설명합니다. 그런 다음 유연한 어댑터나 관리자가 세부적인 작업을 처리하도록 하세요.
예:
class PostAdapter extends APIAdapter {
static baseURL = 'https://jsonplaceholder.typicode.com/';
static headers = {};
static endpoint = 'posts';
async *all(...args){
// Insert custom business logic here (e.g., logging, pagination)
return await super.all(...args)
}
}
class UserAdapter extends APIAdapter {
static baseURL = 'https://dummyjson.com/';
static headers = {};
static endpoint = 'users';
}
class CustomValidatedPost extends Post {
static schema = {
...Post.schema,
email: 'string',
body: 'string',
userId: 'number'
};
static adapter = PostAdapter;
}
class CustomUser extends User {
static adapter = UserAdapter;
async _post() {
return await CustomValidatedPost.objects.query({ id: this.id });
}
}
// Using the declared models and adapters:
const userIterator = await CustomUser.objects.all();
async function processNextUser() {
const { value: user, done } = await userIterator.next();
if (done) return;
// Handle your user data here
}
얼핏 보면 클래스, 정적 속성, 어댑터가 있기 때문에 더 복잡해 보일 수 있습니다. 자세히 살펴보세요.
즉, 일련의 지침이라기보다는 일련의 선언에 더 가까운 내용을 읽는 시스템을 구축하는 것입니다. 어댑터와 모델은 임의의 axios.get() 호출로 구성된 임시 클러스터가 아니라 코드의 나머지 부분이 의존할 수 있는 패턴을 형성합니다.
이런 노력을 하는 이유는 무엇인가요? 프로젝트가 성장함에 따라 명령형 논리의 지뢰밭을 탐색하는 데 시간을 낭비하고 싶지 않기 때문입니다. 선언적 디자인은 기대치를 설정합니다.
이 접근 방식은 개발자로서의 지능을 존중합니다. 어떤 엔드포인트가 어떤 모델에 속해 있는지 또는 헤더가 어디에 정의되어 있는지 기억하도록 강요하지 않습니다. 대신 더 높은 수준에서 생각할 수 있습니다. 데이터의 모양과 관련성을 정의하고 나머지는 프레임워크에서 처리하도록 하세요.
우리는 어댑터와 정적 필드를 사용한 선언적 접근 방식이 원시 명령형 코드보다 보편적으로 더 낫다고 주장하는 것이 아닙니다. 작은 스크립트의 경우 axios.get()만 있으면 됩니다. 그러나 시스템이 확장됨에 따라 선언적 접근 방식은 변경이 덜 고통스럽고 기능을 추가하기가 더 쉬우며 전반적인 복잡성이 적절하게 관리되는 지속 가능한 환경을 조성합니다.
개발자를 지시사항을 기록하는 사람이 아니라 똑똑한 엔지니어처럼 대하는 시스템을 구축하는 것이라고 할 수 있습니다.
모든 단계를 손으로 작성하는 데 익숙하다면 선언적 접근 방식이 처음에는 낯설게 느껴질 수도 있습니다. 그러나 일관된 패턴, 명확하게 선언된 엔드포인트, 사용자 정의 논리를 깔끔하게 추가할 수 있는 공간의 평온함을 경험하고 나면 명령형 확장으로 돌아가기가 어려워집니다.
우월성을 입증하려는 것이 아닙니다. 이는 미래의 자신에게 더 친절하고, 시간을 더 존중하며, 데이터와 관계에 대해 생각하는 방식에 더 부합하는 접근 방식을 제공하는 것입니다. 모든 요청을 세세하게 관리하는 대신 어떻게얻는지에 대한 모든 지루한 세부사항이 아니라 원하는 무엇
에 초점을 맞춰 이야기처럼 읽는 코드를 작성합니다.위 내용은 개발자로서의 지능을 존중하기 위해 선언적 데이터 액세스 수용의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
