최신 WordPress 개발에 접근하는 방법(2부)

게시 됨: 2022-03-11

WordPress는 지구상에서 가장 널리 사용되는 사이트 기술이며 그럴만한 이유가 있습니다. 그러나 핵심에 있는 레거시 코드는 엉망이며 이 문제는 타사 개발자에게 연쇄적으로 영향을 미칩니다. 일부 개발자는 이것을 자신의 WordPress PHP 코드에서 모서리를 자르기 위한 핑계로 삼지만, 이 접근 방식은 가장 사소한 변경을 제외하고 장기적으로 볼 때 더 비쌉니다.

2부로 구성된 시리즈의 1부에서는 전체 프로젝트 및 워크플로 도구에 초점을 맞춘 다음 프런트 엔드 개발에 중점을 두었습니다. 이제 황소를 뿔뿔이 흩어지게 하고 PHP와 씨름해야 할 때입니다. 특히 백엔드 WordPress 코드로 작업할 때 모범 사례를 따르는 방법입니다. 이것을 PHP/WordPress 튜토리얼로 생각할 수 있지만, 이미 WordPress 백엔드 사용자 정의를 일부 수행했다는 가정 하에 좀 더 고급입니다.

그렇다면 어떤 최신 소프트웨어 설계 원칙과 PHP 기능이 시간에 최고의 가치를 제공할 것입니까? 다음은 내가 적극 권장하는 10가지 WordPress 및 PHP 개발 사례입니다.

최신 WordPress 개발 모범 사례 #1: "우려 분리" 따르기

관심사의 분리는 기능이나 목적이 다른 WordPress PHP 코드의 일부가 함께 혼합되어서는 안 된다는 것을 의미합니다. 대신 정의된 인터페이스를 통해 데이터를 서로 전달하면서 별개의 섹션이나 모듈로 구성해야 합니다. ( 인터페이스 는 모듈이 입력으로 사용하는 정의된 매개변수의 집합이며 모듈이 다시 출력하는 것입니다.) 밀접하게 관련된 용어는 단일 책임 원칙 입니다. 모든 코드 모듈(또는 기능)은 한 가지만 책임져야 합니다.

이러한 원칙을 따르는 궁극적인 목표는 모듈식 코드를 생성하여 유지보수, 확장 및 재사용이 가능한 코드를 생성하는 것입니다.

그것은 한 입 가득 찼으므로 모든 것이 얽힌 일부 WordPress PHP(WordPress 코어에서)의 예를 살펴보겠습니다. 이러한 스타일의 코딩은 내부 동작을 이해하는 것이 거의 불가능하기 때문에 종종 "스파게티 코드"라고 합니다. 아래 발췌문은 간결함을 위해 수정되었습니다. 그러나 원래 스타일과 서식은 유지되었습니다.

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

우선, 완전히 이해할 수 없습니다. 그리고 나는 유일한 코멘트가 완전히 중복되는 End foreach 라는 것을 좋아합니다. 우리는 데이터베이스 쿼리, 쿼리 결과 처리, HTML에 포함된 추가 처리(당신이 눈치채지 못했다면 거기에 if / else 중첩되어 있음), 출력 이스케이프 및 HTML 템플릿이 모두 함께 매쉬되었습니다. 또 다른 문제는 실제 매개변수를 함수에 전달하는 것과는 대조적으로 전역 $_REQUEST 에서 직접 오는 $id 매개변수입니다.

이것을 보면 WordPress 코어가 수년간 거의 동일하게 유지되는 이유를 완벽하게 이해할 수 있습니다. 특히 기존 동작을 유지하면서 이러한 종류의 코드를 리팩토링하는 것은 누구도 하고 싶어하지 않는 정말 장대한 작업입니다.

그렇다면 어떻게 해야 제대로 할 수 있을까요? 음, 기억해야 할 한 가지는 진정한 방법은 없다는 것입니다. 위에서 우리가 노력해야 할 자질을 언급했습니다. 유지 관리가 가능하고 모듈화되기 위해서는 WordPress 사용자 정의 PHP 코드가 필요합니다. 위의 코드를 모듈로 분할하는 방법을 살펴보겠습니다.

  • SQL 쿼리는 분명히 별도의 모듈에 있어야 합니다. WordPress에는 이미 예제로 사용해야 하는 멋지게 추상화된 WP_Query 클래스가 있습니다.
  • 모든 HTML은 템플릿으로 들어갑니다. 우리는 아래에서 PHP 템플릿을 더 다룰 것입니다.
  • 나머지 PHP 코드는 하나의 함수에 대해 코드가 너무 길거나 복잡한 경우 여러 함수를 함수로 래핑해야 합니다. $id 와 같은 매개변수는 함수 인수를 통해 전달됩니다.

이것은 위의 예를 크게 단순화한 것입니다.

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

최신 WordPress 개발 모범 사례 #2: 전역 변수 피하기

WordPress에는 너무 많은 전역 변수가 있습니다. 전역 변수가 나쁜 이유는 무엇입니까? 그들은 WordPress PHP 코드를 따르기 어렵게 만들고 애플리케이션 상태를 신뢰할 수 없게 만듭니다. 모든 PHP 코드, 즉 WordPress에 설치된 모든 플러그인은 전역 변수를 읽고 쓸 수 있으므로 유효한 데이터가 포함되어 있다는 보장이 없습니다. 루프와 같은 것에서 어떤 전역 변수가 사용되는지 이해하는 것도 쉬운 일이 아닙니다.

이것을 실용적인 관점에서 살펴보자. 이 예제는 WooCommerce에서 가져온 것입니다. 아마도 모든 WordPress 개발자는 루프가 무엇인지 알고 있을 것입니다.

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

위의 스니펫은 제품 템플릿을 렌더링합니다. wc_get_template_part 에 전달된 매개변수가 없는 경우 표시할 제품을 어떻게 알 수 있습니까? 템플릿을 보면 global $product; , 그래서 현재 제품 개체가 저장됩니다.

이제 제품을 검색하고 필터링하는 카탈로그 페이지가 있고 동일한 페이지에 있는 동안 "제품 세부정보" 팝업을 표시하려고 한다고 상상해 보십시오. 이면에서 프론트엔드 스크립트는 특정 제품 템플릿을 가져오기 위해 AJAX 요청을 수행합니다. 매개변수를 사용하지 않기 때문에 단순히 wc_get_template_part('content', 'single-product') 를 호출할 수 없습니다. 따라서 이것이 작동하려면 몇 가지 전역 변수를 설정해야 합니다.

더 복잡한 사용 사례에는 둘 이상의 템플릿, 해당 템플릿에서 트리거된 후크 및 해당 후크에 콜백을 추가하는 타사 플러그인이 포함됩니다. 빠르게 확대될 수 있습니다. 이러한 콜백이 의존하는 전역 상태를 알 수 있는 방법이 없습니다. 타사 플러그인은 콜백에서 전역 변수를 자유롭게 수정할 수 있습니다. 시스템을 사용하는 대신 시스템과 싸우기 시작하여 신뢰할 수 없는 글로벌 상태에서 발생하는 이상한 버그에 직면합니다.

해당 제품 ID를 매개변수로 전달하는 것이 더 합리적이지 않을까요? 그런 다음 WordPress에서 사용하는 전역 변수를 망칠 염려 없이 해당 템플릿을 재사용할 수 있습니다.

최신 WordPress 개발 모범 사례 #3: 객체 지향 프로그래밍(OOP) 사용

모듈화는 객체 및 객체 지향 프로그래밍의 개념으로 이어집니다. 매우 기본적인 수준에서 OOP는 코드를 구성하는 방법입니다. 함수와 변수는 함께 클래스로 묶여 있으며 각각 클래스 메서드 및 속성 이라고 합니다. WordPress 플러그인 핸드북은 WordPress 사용자 정의 PHP 코드를 구성하기 위해 OOP를 사용할 것을 권장합니다.

private 의 protected 원칙은 메서드 및 속성에 대한 액세스를 제한하는 것입니다. 이에 대한 OOP 용어는 캡슐화 입니다. 데이터는 클래스 내부에 캡슐화되며 해당 데이터를 변경하는 유일한 방법은 제공된 클래스 메서드를 사용하는 것입니다.

이렇게 하면 전체 코드베이스의 어느 곳에서나 수정할 수 있는 전역 변수를 사용할 때보다 훨씬 쉽게 코드를 디버깅하고 유지 관리할 수 있습니다. 전역 WordPress post 변수를 고려하십시오. 코드의 어디에서나 액세스할 수 있으며 많은 기능이 사용에 따라 다릅니다. 워드프레스 핵심 기능만 수정하도록 제한할 수 있지만 읽기는 누구에게나 허용된다면 어떨까요? 클래스에서 전역 post 변수를 숨기거나 캡슐화하고 주변에 인터페이스를 구축하면 이것이 가능합니다.

이것은 OOP에 대한 매우 기본적인 설명일 뿐이며 현대 WordPress 개발에서 사용되는 방법입니다. 더 많은 연구를 위해 나는 WordPress의 OOP 주제에 대해 사용할 수 있는 가장 포괄적이고 유용한 콘텐츠가 있는 Carl Alexander의 전자 책 Discover object-oriented programming using WordPress를 강력히 추천합니다.

OOP는 만병통치약이 아니라는 점을 기억하는 것이 중요합니다. 잘못된 코드는 다른 프로그래밍 패러다임과 마찬가지로 OOP로 쉽게 작성할 수 있습니다.

WordPress 개발에 PHP를 사용하는 것에 대한 몇 가지 구체적인 조언을 살펴보겠습니다.

최신 PHP 모범 사례 #1: PHP 7.0 이상 대상

최신 PHP 기능을 사용하려면 최신 버전의 PHP가 필요합니다. PHP 7.0 미만 버전을 지원할 이유가 없습니다. WordPress 코어조차도 빠르면 2019년 말에 PHP 7.0이 필요합니다.

그럼에도 불구하고 호환되지 않는 환경에서 "죽음의 흰색 화면"을 피하기 위해 최소 버전을 확인하는 것이 좋습니다. 아래 스니펫은 플러그인 헤더를 사용하여 코드에 보호 조건이 있는 최소 PHP 버전을 선언하는 방법을 보여줍니다.

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

최신 PHP 모범 사례 #2: PHP 산업 표준 채택(PSR-2 코딩 스타일 가이드)

PSR은 PHP Framework Interop Group에서 게시한 권장 사항입니다. 이는 모든 현대 PHP 워크플로에서 사실상의 산업 표준이며 PHP 커뮤니티 전체가 이러한 표준을 따르고 있다고 안전하게 말할 수 있습니다. PSR-2는 코딩 스타일을 설명하는 권장 사항입니다. Symfony 및 Laravel과 같은 인기 있는 PHP 프레임워크는 PSR-2를 따릅니다.

WordPress 코딩 표준 대신 PSR-2를 사용하는 이유는 무엇입니까? 주로 WordPress 표준이 더 이상 사용되지 않고 새로운 언어 기능을 사용하지 않기 때문입니다. WordPress 코어는 자체 표준을 따라야 하기 때문에 이해할 수 있습니다. 아주 최근까지 PHP 5.2를 지원해야 했고 PSR-2는 PHP 5.2와 호환되지 않습니다.

명확하지 않을 수 있지만 핵심에 전념하지 않는 한 WordPress 코딩 표준을 사용해야 하는 요구 사항은 없습니다. PSR-2 표준을 따르는 플러그인을 WordPress 플러그인 디렉토리에 제출하는 데 문제가 없습니다. 사실, 그렇게 하는 데에는 몇 가지 아주 좋은 주장이 있습니다.

최신 PHP 모범 사례 #3: PHP 템플릿 엔진 사용

PHP는 템플릿 엔진이 아닙니다. 하나로 시작했지만 모든 기능을 갖춘 프로그래밍 언어로 발전했고 템플릿에 계속 사용할 이유가 없습니다. PHP용으로 가장 널리 사용되는 두 가지 템플릿 엔진은 각각 Symfony와 Laravel에서 사용하는 Twig와 Blade입니다. 이 기사에서는 Twig를 예제 템플릿 엔진으로 사용할 것입니다. 그러나 Blade에는 유사한 기능이 있습니다. 둘 다 살펴보고 가장 적합한 것을 스스로 결정하기를 바랍니다.

아래 예는 PHP 템플릿과 해당 Twig 템플릿을 비교합니다. 출력을 표시하고 이스케이프하는 것은 PHP 예제에서 특히 장황합니다.

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

Twig에서는 다음이 더 간결하고 읽기 쉽습니다.

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

Twig의 주요 장점은 다음과 같습니다.

  • 읽기 쉽고 간결한 구문
  • 자동 출력 이스케이프
  • 상속 및 블록을 통한 템플릿 확장

성능 면에서 Twig는 PHP 템플릿으로 컴파일되며 사실상 오버헤드가 없습니다. Twig에는 템플릿으로만 제한된 PHP 언어 구성의 하위 집합만 있습니다. 이로 인해 개발자는 템플릿에서 비즈니스 로직을 제거해야 하므로 우려 사항을 분리해야 합니다.

WordPress용 Twig도 있습니다. 그것은 Timber라고 하며 더 나은 템플릿을 만드는 것을 시작할 수 있는 좋은 방법입니다. Timber 스타터 테마는 OOP 방식으로 테마를 구성하는 완벽한 예입니다.

최신 PHP 모범 사례 #4: Composer 사용

Composer는 PHP용 종속성 관리자입니다. 프로젝트에서 사용 중인 라이브러리를 선언한 다음 다운로드, 설치 및 업데이트를 자동화할 수 있는 도구입니다. 그런 다음 각 라이브러리를 수동으로 요구하는 대신 Composer의 자동 로드 파일 vendor/autoload.php 를 포함하기만 하면 됩니다.

WordPress 플러그인 및 테마는 타사 라이브러리를 자주 사용하지 않습니다. 이는 부분적으로 WordPress에 거의 모든 요구 사항을 충족하는 광범위한 API가 있고 부분적으로 가능한 버전 충돌 때문입니다. 동일한 PHP 라이브러리를 필요로 하지만 다른 버전을 필요로 하는 두 개의 플러그인을 고려하십시오. 먼저 실행되는 플러그인은 올바른 버전을 가져오고 두 번째 플러그인은 해당 버전도 가져옵니다. 이것은 또 다른 죽음의 화면 같은 상황일 가능성이 큽니다.

충돌을 피하려면 애플리케이션 수준, 즉 WordPress 사이트 전체에서 종속성 관리를 사용해야 합니다. 이것이 Roots(Bedrock, 보다 구체적으로)가 하는 일입니다. 패키지(플러그인 또는 테마) 수준에서 사용하는 경우 Composer는 타사 라이브러리를 사용할 때 충돌을 일으킬 수 있습니다. 알려진 문제입니다. 지금까지 존재하는 유일한 해결책은 외부 라이브러리의 이름 공간을 고유한 이름으로 바꾸는 것인데, 이는 쉬운 일이 아닙니다.

하지만 Composer는 여전히 사용할 수 있습니다. 바로 자신의 클래스를 자동으로 로드하는 것입니다. 그러나 자동 로딩을 더 진행하기 전에 PHP 네임스페이스에 대한 속도를 높여야 합니다.

최신 PHP 모범 사례 #5: 네임스페이스 사용

WordPress 코어는 레거시 프로젝트이므로 전역 네임스페이스를 사용하거나 다르게 말하면 네임스페이스가 전혀 사용되지 않습니다. 전역적으로 선언된 모든 클래스 또는 함수(다른 클래스 또는 함수 내부가 아님을 의미)는 전체 코드베이스의 어느 곳에서나 볼 수 있습니다. 이름은 코드베이스 내에서뿐만 아니라 현재 사용 중이거나 앞으로 사용될 모든 플러그인 및 테마에 대해 고유해야 합니다.

이름 충돌(예: 이미 존재하는 이름으로 함수 선언)은 일반적으로 흰색 죽음의 화면으로 이어지며 우리는 그것을 원하지 않습니다. WordPress Codex는 모든 기능과 클래스에 고유한 접두사를 붙일 것을 권장합니다. 따라서 Order 와 같은 간단한 클래스 이름을 사용하는 대신 Akrte_Awesome_Plugin_Order 와 같은 것을 얻습니다. 여기서 "Akrte"는 제가 방금 만든 고유 접두사입니다.

네임스페이스는 코드를 구성하고 이름 충돌을 방지하는 데 도움이 되는 그룹(또는 파일 시스템 비유를 사용하는 경우 폴더)으로 볼 수 있습니다. 중첩된 폴더처럼 슬래시로 구분된 복잡한 네임스페이스를 가질 수 있습니다. (PHP 네임스페이스는 특히 백슬래시를 사용합니다.)

이러한 네임스페이스 부분을 하위 네임스페이스라고 합니다. Akrte_Awesome_Plugin_Order 예제 클래스는 네임스페이스를 사용하여 완료되는 경우 Akrte\Awesome_Plugin\Order 가 됩니다. 여기서 Akrte 와 Awesome_Plugin 은 네임스페이스 부분(또는 하위 네임스페이스)이고 Order 는 클래스 이름입니다. 그런 다음 use 문을 추가하고 나중에 클래스 이름만 사용할 수 있습니다. 확실히 더 좋아 보입니다.

 use Akrte\Awesome_Plugin\Order; $a = new Order;

분명히 네임스페이스는 고유해야 합니다. 따라서 첫 번째 "루트" 하위 네임스페이스에 고유한 이름을 지정해야 하며 이는 일반적으로 공급업체 이름입니다. 예를 들어 WooCommerce 클래스 WC_REST_Order_Notes_V2_Controller 는 다음과 같은 네임스페이스로 다시 수행할 수 있습니다.

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

WooCommerce 코드베이스는 요즘 네임스페이스를 사용합니다. 예를 들어 WooCommerce REST API 버전 4.

최신 PHP 모범 사례 #6: 자동 로더 사용

대부분의 PHP 워크플로에서 PHP 파일을 함께 연결하는 일반적인 방법은 require 또는 include 문을 사용하는 것입니다. 프로젝트가 성장함에 따라 기본 플러그인 파일에 수십 개의 require 문을 얻게 됩니다. 자동 로더는 파일 포함을 자동화하고 필요할 때만 수행합니다. 기술적으로 코드에서 처음 발견될 때 클래스 또는 함수를 포함하는 sa 파일이 require 함수입니다. 더 이상 수동으로 require 문을 추가할 필요가 없습니다.

자동 로더는 특정 요청에 사용되는 모듈만 로드하기 때문에 종종 상당한 성능 향상이 있습니다. 자동 로더가 없으면 요청에서 코드의 10%만 사용하더라도 전체 코드베이스가 포함됩니다.

자동 로더 함수는 클래스와 함수가 있는 파일을 알아야 합니다. 그리고 이를 위한 PHP-FIG 표준인 PSR-4가 있습니다.

네임스페이스의 일부인 접두사를 기본 폴더에 해당하도록 지정했다고 합니다. 그 뒤에 오는 하위 네임스페이스는 기본 폴더 내의 폴더에 해당합니다. 마지막으로 클래스 이름은 파일 이름에 해당합니다. 예제 클래스 Akrte\AwesomePlugin\Models\Order 에는 아래 폴더 구조가 필요합니다.

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

네임스페이스 접두사 Akrte\AwesomePlugin\ 은 아래에서 설명하는 자동 로더 구성에 지정된 includes 폴더에 해당합니다. Models 하위 네임스페이스에는 해당 Models 폴더가 있으며 Order 클래스는 Order.php 에 포함되어 있습니다.

다행히 자동 로더 기능을 직접 구현할 필요는 없습니다. Composer는 자동 로더를 생성할 수 있습니다.

  1. 작곡가 설치
  2. 프로젝트의 루트 폴더에 composer.json 파일을 만듭니다. 다음 행을 포함해야 합니다.
 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }
  1. composer install 실행합니다.
  2. 다음과 같이 기본 플러그인 PHP 파일 상단에 vendor/autoload.php 를 포함합니다.
 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

네임스페이스 외에도 WooCommerce의 최신 코드베이스는 Composer 자동 로더도 사용합니다.

이러한 PHP 디자인 원칙을 다루었으므로 마지막 권장 사항으로 모든 PHP 수업을 WordPress 백엔드 사용자 지정과 다시 연결해야 합니다.

최신 WordPress 개발 모범 사례 #4: 루트 스택 사용 고려

Roots는 가장 포괄적인 최신 WordPress 개발 워크플로입니다. 그러나 다음과 같은 이유로 모든 WordPress 프로젝트에서 반드시 사용해야 하는 것은 아닙니다.

  • 루트는 처음부터 사용해야 합니다. 가장 흔한 이유입니다. 기존 프로젝트를 리팩토링하는 것은 비용이 너무 많이 듭니다.
  • 의견이 분분합니다. 동의하면 좋고, 동의하지 않으면 나쁩니다. 예를 들어 테마를 구성하는 다른 방법을 선호할 수 있습니다. 의견이 있는 프로젝트는 또한 "그들의 방식"을 배우는 데 시간이 필요합니다.
  • 모두가 아는 것은 아닙니다. Roots 스택으로 구축한 사이트를 유지 관리하기 위해 당신을 뒤따를 개발자는 그것이 무엇인지 모르고 WordPress 폴더에 무슨 일이 일어났는지 궁금해할 수 있습니다. 동료 WordPress 개발자에 대해 생각해야 합니다.

일반적으로 의견이 강한 프로젝트를 사용하기로 결정하기 전에 모든 장점과 단점을 완전히 이해하고 싶을 것입니다.

최신 PHP 및 소프트웨어 원칙: WordPress 백엔드 개발을 강력하게 만들기

소프트웨어를 작성하는 진정한 방법은 없다는 것이 상당히 분명합니다. 관심사 분리와 같은 개념은 수십 년이 지났습니다. 그러나 그것이 실질적으로 의미하는 바는 항상 논쟁거리였습니다. 예를 들어 CSS를 보자. 처음에는 HTML의 style 로 인라인 처리한 다음 별도의 CSS 시트가 관심사의 분리에 관한 것이라고 결정했습니다.

10년을 빨리 감기: 현재의 JavaScript 앱은 구성 요소 를 관심 분리 구현으로 사용합니다. 프론트 엔드 개발자는 CSS-in-JS에 끌립니다. 이는 기본적으로 HTML에서 CSS를 다시 인라인하는 것을 의미합니다. 원이 완성되었습니다!

모범 사례는 항상 개발자 경험 개선에 관한 것이었습니다.

프로그램은 사람이 읽을 수 있도록 작성되어야 하며, 기계가 실행하기 위해서는 부수적으로만 작성해야 합니다.

Abelson & Sussman, 컴퓨터 프로그램의 구조와 해석

이 PHP WordPress 튜토리얼의 일부 사례는 프로젝트에서 빠르고 쉽게 구현할 수 있습니다. 예를 들어 autoloader: 프로젝트당 한 번만 수행하고 즐기십시오. 반면에 새로운 소프트웨어 아키텍처 아이디어는 시간과 연습이 필요하고 편리하고 익숙해지기 위해 수많은 반복 작업이 필요합니다. 그러나 보상은 훨씬 더 큽니다. 당신은 당신이 하는 일을 더 효율적으로 할 뿐만 아니라 당신이 하는 일을 더 즐길 수 있을 것입니다. 그리고 고객을 위해 하는 일을 정기적으로 즐기는 것이 아마도 지속 가능한 유일한 방법일 것입니다.