WordPress 플러그인을 개발하면서 배운 교훈

모든 WordPress 플러그인 개발자는 유지 관리하기 어려운 어려운 문제와 코드로 어려움을 겪습니다. 우리는 사용자를 지원하기 위해 늦은 밤을 보내고 업그레이드로 인해 플러그인이 중단되면 머리카락을 찢습니다. 쉽게 만드는 방법을 알려드리겠습니다.

이 기사에서는 5년 동안 WordPress 플러그인을 개발한 경험을 공유합니다. 내가 작성한 첫 번째 플러그인은 간단한 마케팅 플러그인이었습니다. 구글의 검색어와 함께 클릭 유도문안(CTA) 버튼을 표시했다. 그 이후로 11개의 무료 플러그인을 추가로 작성했으며 거의 ​​모든 플러그인을 유지 관리하고 있습니다. 나는 아주 작은 것부터 지금까지 1년 이상 유지된 것에 이르기까지 내 클라이언트를 위해 약 40개의 플러그인을 작성했습니다.

좋은 개발과 지원은 더 많은 다운로드로 이어집니다. 더 많은 다운로드는 더 많은 돈과 더 나은 평판을 의미합니다. 이 기사는 플러그인 개발을 개선할 수 있도록 내가 배운 교훈과 내가 저지른 실수를 보여줄 것입니다.

1. 문제 해결

플러그인으로 문제가 해결되지 않으면 다운로드되지 않습니다. 그것만큼 간단합니다.

Advanced Cron Manager 플러그인을 사용하십시오(8,000개 이상의 활성 설치). cron 디버깅에 어려움을 겪고 있는 WordPress 사용자에게 도움이 됩니다. 플러그인은 필요에 따라 작성되었습니다. 저는 제 자신을 도울 무언가가 필요했습니다. 사람들이 이미 그것을 필요로 했기 때문에 나는 이것을 시장에 내놓을 필요가 없었습니다. 그것은 그들의 가려움을 긁었습니다.

반면에 Bug — fly on the screen 플러그인(70개 이상의 활성 설치)이 있습니다. 그것은 무작위로 화면에 파리를 시뮬레이션합니다. 그것은 실제로 문제를 해결하지 않으므로 많은 청중을 갖지 않을 것입니다. 그래도 개발하는 재미있는 플러그인이었습니다.

문제에 집중하세요. 사람들은 SEO가 잘 수행되지 않는 것을 볼 때 SEO 플러그인을 설치합니다. 사람들이 웹사이트 속도를 높이고 싶을 때 캐싱 플러그인을 설치합니다. 사람들이 자신의 문제에 대한 솔루션을 찾을 수 없을 때 자신을 위한 솔루션을 작성하는 개발자를 찾습니다.

David Hehenberger가 성공적인 플러그인 작성에 대한 자신의 기사에서 증명했듯이, 필요는 특정 플러그인을 설치할지 여부를 WordPress 사용자가 결정하는 핵심 요소입니다.

누군가의 문제를 해결할 기회가 있다면 기회를 잡으십시오.

2. 제품 지원

“미국인 5명 중 3명은 더 나은 서비스 경험을 위해 새로운 브랜드나 회사를 시도할 것입니다. 10명 중 7명은 우수한 서비스를 제공한다고 생각하는 회사에 더 많은 비용을 지출할 의향이 있다고 말했습니다.”

— 니키 예거

당신의 지원을 게을리 하지 마십시오. 필수품으로 여기지 말고 기회로 삼으십시오.

플러그인이 성장하려면 양질의 지원이 중요합니다. 최고의 코드를 가진 플러그인도 일부 지원 티켓을 받게 됩니다. 플러그인을 사용하는 사람이 많을수록 더 많은 티켓을 받을 수 있습니다. 더 나은 사용자 경험은 더 적은 수의 티켓을 얻을 수 있지만 받은 편지함에 도달할 수 없습니다.

누군가가 지원 포럼에 메시지를 게시할 때마다 즉시 이메일 알림을 받고 최대한 빨리 응답합니다. 그것은 돈을 지불합니다. 내 좋은 리뷰의 대부분은 지원 덕분에 얻었습니다. 이것은 부작용입니다. 좋은 지원은 종종 별 5개 리뷰로 이어집니다.

당신이 훌륭한 지원을 제공할 때 사람들은 당신과 당신의 제품을 신뢰하기 시작합니다. 플러그인은 완전히 무료이며 오픈 소스인 경우에도 하나의 제품입니다.

좋은 지원은 하루에 한 번 짧은 답변을 작성하는 것보다 더 복잡합니다. 플러그인이 인기를 얻으면 하루에 여러 티켓을 받게 됩니다. 능동적이고 고객이 묻기도 전에 고객의 질문에 답하면 관리가 훨씬 쉽습니다.

취할 수 있는 조치 목록은 다음과 같습니다.

• 리포지토리에 FAQ 섹션을 만듭니다.
• 지원 포럼 상단에 "질문하기 전에" 스레드를 고정하여 문제 해결 팁과 FAQ를 강조 표시합니다.
• 플러그인이 사용하기 쉽고 사용자가 플러그인을 설치한 후 해야 할 일을 알고 있는지 확인하십시오. UX가 중요합니다.
• 지원 질문을 분석하고 문제점을 수정하십시오. 사람들이 원하는 기능에 대해 투표할 수 있는 게시판을 설정합니다.
• 플러그인 작동 방식을 보여주는 비디오를 만들고 WordPress.org 저장소의 플러그인 기본 페이지에 추가하십시오.

제품을 지원하는 데 사용하는 소프트웨어는 중요하지 않습니다. WordPress.org의 공식 지원 포럼은 이메일 또는 자체 지원 시스템과 마찬가지로 작동합니다. 무료 플러그인에는 WordPress.org의 포럼을 사용하고 프리미엄 플러그인에는 자체 시스템을 사용합니다.

3. 작곡가를 사용하지 마십시오

Composer는 패키지 관리자 소프트웨어입니다. 패키지 저장소는 packagist.org에서 호스팅되며 프로젝트에 쉽게 다운로드할 수 있습니다. PHP용 NPM 또는 Bower와 같습니다. Composer가 하는 방식으로 타사 패키지를 관리하는 것이 좋은 방법이지만 WordPress 프로젝트에서는 사용하지 마십시오.

알아, 내가 폭탄을 떨어뜨렸다. 설명하겠습니다.

Composer는 훌륭한 소프트웨어입니다. 직접 사용하지만 공개 WordPress 프로젝트에서는 사용하지 않습니다. 문제는 갈등에 있습니다. 워드프레스에는 글로벌 패키지 관리자가 없으므로 모든 플러그인은 자체 종속성을 로드해야 합니다. 두 개의 플러그인이 동일한 종속성을 로드하면 치명적인 오류가 발생합니다.

이 문제에 대한 이상적인 해결책은 없지만 Composer는 문제를 더욱 악화시킵니다. 소스의 종속성을 수동으로 묶고 로드해도 안전한지 항상 확인할 수 있습니다.

Composer의 WordPress 플러그인 문제는 아직 해결되지 않았으며 가까운 장래에 이 문제에 대한 실행 가능한 솔루션이 없을 것입니다. 문제는 수년 전에 제기되었으며 WP Tavern의 기사에서 읽을 수 있듯이 많은 개발자가 운 없이 해결하려고 합니다.

당신이 할 수 있는 최선은 조건과 환경이 코드를 실행하기에 좋은지 확인하는 것입니다.

4. 이전 PHP 버전을 합리적으로 지원

5.2와 같은 아주 오래된 버전의 PHP를 지원하지 마십시오. 보안 문제 및 유지 관리는 그만한 가치가 없으며 이전 버전에서 더 많은 설치를 얻을 수 없습니다.

공식 지원이 2018년 말까지 중단되더라도 최소 요구 사항으로 PHP 5.6을 사용하세요. WordPress 자체에는 PHP 7.2가 필요합니다.

레거시 PHP 버전의 지원을 방해하는 움직임이 있습니다. Yoast 팀은 플러그인에 포함할 수 있고 사용자에게 PHP 버전 및 업그레이드해야 하는 이유에 대한 중요한 정보를 표시하는 Whip 라이브러리를 출시했습니다.

지원하는 버전을 사용자에게 알리고 플러그인이 너무 낮은 버전에 설치된 후에도 웹사이트가 중단되지 않는지 확인하십시오.

5. 품질 코드에 초점

좋은 코드를 작성하는 것은 처음에는 어렵습니다. "SOLID" 원칙과 디자인 패턴을 배우고 오래된 코딩 습관을 바꾸는 데는 시간이 걸립니다.

더 나은 코딩 방법을 사용하여 플러그인 중 하나를 다시 작성하기로 결정했을 때 WordPress에 간단한 문자열을 표시하는 데 3일이 걸렸습니다. 30분을 기다려야 한다는 사실이 안타까웠다. 사고방식을 바꾸는 것은 고통스러웠지만 가치가 있었습니다.

왜 그렇게 힘들었을까? 처음에는 과도하고 직관적이지 않은 것처럼 보이는 코드를 작성하기 시작하기 때문입니다. "이것이 정말 필요한가?" 예를 들어 논리를 다른 클래스로 분리하고 각각이 단일 항목을 담당하는지 확인해야 합니다. 또한 번역, 사용자 정의 포스트 유형 등록, 자산 관리, 양식 핸들러 등을 위한 클래스를 분리해야 합니다. 그런 다음 간단한 작은 개체에서 더 큰 구조를 구성합니다. 의존성 주입이라고 합니다. 이는 모든 코드를 벼락치기 위한 "프론트 엔드" 및 "관리자" 클래스와 매우 다릅니다.

직관적이지 않은 다른 방법은 모든 작업과 필터를 생성자 메서드 외부에 유지하는 것이었습니다. 이렇게 하면 개체를 만드는 동안 작업을 호출하지 않으므로 단위 테스트에 매우 유용합니다. 또한 어떤 메서드가 언제 실행되는지 더 잘 제어할 수 있습니다. 생성자 메서드의 작업으로 인해 무한 루프가 있는 프로젝트를 작성하기 전에 이것을 알았더라면 좋았을 것입니다. 이러한 종류의 버그는 추적하기 어렵고 수정하기 어렵습니다. 프로젝트를 리팩토링해야 했습니다.

위의 내용은 몇 가지 예에 불과하지만 SOLID 원칙을 알아야 합니다. 이는 모든 시스템 및 코딩 언어에 유효합니다.

모든 모범 사례를 따르면 모든 새로운 기능이 딱 들어맞는 지점에 도달합니다. 기존 코드를 수정하거나 예외를 만들 필요가 없습니다. 놀랍다. 코드가 더 복잡해지는 대신 유연성을 잃지 않으면서 더 발전합니다.

또한 코드 형식을 올바르게 지정하고 팀의 모든 구성원이 표준을 따르도록 하십시오. 표준은 코드를 예측 가능하고 읽기 및 테스트하기 쉽게 만듭니다. WordPress에는 프로젝트에서 구현할 수 있는 자체 표준이 있습니다.

6. 미리 플러그인 테스트

나는 이 교훈을 열심히 배웠다. 테스트 부족으로 치명적인 오류가 있는 새 버전의 플러그인을 출시하게 되었습니다. 두 배. 두 번 모두 별점 1개를 받았지만 긍정적인 평가로 이어지지는 않았습니다.

수동 또는 자동으로 테스트할 수 있습니다. Travis CI는 GitHub와 통합되는 지속적인 테스트 제품입니다. 플러그인이 모든 PHP 버전에서 제대로 부팅할 수 있는지 여부를 확인하는 알림 플러그인을 위한 정말 간단한 테스트 모음을 만들었습니다. 이렇게 하면 플러그인에 오류가 없는지 확인할 수 있으며 모든 환경에서 플러그인을 테스트하는 데 많은 주의를 기울일 필요가 없습니다.

각 자동화된 테스트는 1초 미만이 소요됩니다. 100개의 자동 테스트를 완료하는 데 약 10분이 소요되는 반면 수동 테스트는 각 사례에 대해 약 2분이 소요됩니다.

플러그인 테스트에 더 많은 시간을 투자할수록 장기적으로 더 많은 비용을 절약할 수 있습니다.

자동화된 테스트를 시작하려면 필요한 모든 구성을 설치하는 WP-CLI \\`wp scaffold plugin-test\\` 명령을 사용할 수 있습니다.

7. 작업 문서화

개발자가 문서 작성을 좋아하지 않는다는 것은 진부한 표현입니다. 개발 과정에서 가장 지루한 부분이지만 조금은 도움이 됩니다.

자체 문서화 코드를 작성하십시오. 변수, 함수 및 클래스 이름에 주의하십시오. 캐스케이드처럼 쉽게 읽을 수 없는 복잡한 구조는 만들지 마세요.

코드를 문서화하는 또 다른 방법은 모든 파일, 함수 및 클래스에 대한 주석인 "doc 블록"을 사용하는 것입니다. 함수가 작동하는 방식과 수행하는 작업을 작성하면 지금부터 6개월 후에 디버그해야 할 때를 훨씬 더 쉽게 이해할 수 있습니다. WordPress 코딩 표준은 문서 블록을 작성하도록 하여 이 부분을 다룹니다.

두 기술을 모두 사용하면 문서 작성 시간을 절약할 수 있지만 코드 문서를 모든 사람이 읽을 수 있는 것은 아닙니다.

최종 사용자의 경우 시스템 작동 방식과 사용 방법을 설명하는 고품질의 짧고 읽기 쉬운 기사를 작성해야 합니다. 비디오가 더 좋습니다. 많은 사람들은 기사를 읽는 것보다 짧은 튜토리얼을 보는 것을 선호합니다. 그들은 코드를 보지 않을 것이므로 그들의 삶을 더 쉽게 만드십시오. 좋은 문서는 또한 지원 티켓을 줄입니다.

결론

이 7가지 규칙은 BracketSpace의 핵심 사업이 되기 시작한 양질의 제품을 개발하는 데 도움이 되었습니다. WordPress 플러그인을 사용하는 여정에도 도움이 되기를 바랍니다.

귀하의 황금 개발 규칙이 무엇인지 또는 위의 항목 중 특히 도움이 되는 항목이 있는지 댓글로 알려주십시오.