WordPress 개발자: 여기에서 시작하세요!

WordPress 개발자를 위한 시작 가이드에 오신 것을 환영합니다! 프리랜서로 일하든 미디어 에이전시의 일원으로 일하든. 이 기사에서는 사용 가능한 리소스 및 도구와 함께 WordPress 개발과 관련된 다양한 주제를 다룰 것입니다.
텍스트는 아이디어 생성과 배송 사이의 다양한 단계를 중심으로 구성되어 있습니다. 우리는 브레인스토밍, 프로토타이핑, 개발, 그리고 마지막으로 배포에 대해 이야기할 것입니다. 이 모든 것이 제품 개발의 맥락에서 이루어집니다. 우리는 아이디어의 첫 번째 암시와 최종 실행 사이에 많은 미묘한 영역이 있다고 믿습니다. 일부는 현재 WordPress 문헌에서 가장 잘 논의되지 않은 상태로 남겨지고 다른 일부는 최악의 경우 완전히 탐구되지 않습니다.  

귀하가 Pressidium 고객이라면 당사 플랫폼을 중심으로 구축한 도구를 즉시 사용할 수 있으므로 높은 수준의 통합 혜택을 누릴 수 있습니다. 우리는 이러한 도구에 대해서도 이야기할 것입니다.   이것은 실제 문서이며 그렇게 취급되어야 함을 기억하십시오.

무엇보다도 우리의 목표는 이 문서가 WordPress 개발자로서의 실습에 유용하고 두 번째로 우리가 당신을 위해 만든 몇 가지 멋진 것을 보여주는 것입니다.

아이디어에서 배포까지  

새로운 제품을 작업하든 클라이언트 작업을 수행하든, 아이디어에서 배포까지의 프로세스는 4단계로 구성됩니다. 이러한 단계는 개별적이지만 상당히 겹치며 선형이 아닙니다. 우리는 이것을 본문에서 더 논의할 것입니다:  

1. 브레인스토밍 및 요구사항 도출.
2. 프로토타이핑.
3. 개발.
4. 전개.

자유 연관 브레인스토밍 프로세스는 제품 또는 프로젝트 구축을 시작하고 아이디어가 필요할 때 사용됩니다. 그러나 요구 사항 수집은 고객을 위한 프로젝트를 구축하거나 브레인스토밍 세션 후에 아이디어를 마무리해야 할 때 발생합니다. 특정 문제를 해결하기 위해 나중에 브레인스토밍 세션을 설정할 수 있지만 이러한 세션은 더 제한됩니다.

브레인스토밍의 기본 원칙은 두 가지입니다. 양을 보고 판단은 나중에 미루세요. 우리는 과거에 그러한 세션을 촉진할 수 있는 방법, 적절한 사고 방식을 구축하는 방법, 도움이 되는 몇 가지 펑키한 도구에 대해 썼습니다.

요구사항 도출

요구 사항을 도출하는 데 사용되는 몇 가지 방법론이 있으며 전통적으로 이것은 항상 비즈니스 분석가의 작업이었습니다. 프로젝트 요구 사항에 대한 정보를 제공하는 것은 클라이언트의 책임이지만 모든 이해 관계자에 대한 공유된 이해가 필요합니다. 요구 사항 도출은 요구 사항 수집과 다른 프로세스입니다. 보다 적극적인 참여를 통해 필요한 정보를 이끌어내는 것입니다. 그리고 클라이언트가 말하는 내용을 수동적으로 문서에 수집하여 개발 팀에 전달하는 것이 아닙니다.

프로젝트의 범위와 특성에 따라 사용 사례는 기능을 캡처하는 좋은 방법입니다. 사용 사례는 시스템의 이해 관계자와 시스템 자체 간의 상호 작용을 설명하는 방법으로 UML 다이어그램에서 사용되는 기술입니다. 그것들은 평범하지만 구조화된 영어로 작성된 시나리오 모음이기 때문에 덜 복잡할 뿐만 아니라 시스템 기능에 대한 논의와 스케치를 시작하는 빠르고 효율적인 방법입니다.

복잡한 제품에 대한 요구 사항을 파악하려면 모든 이해 관계자와 구조화된 인터뷰를 설정해야 할 것입니다. 이를 위해 사용자 스토리는 완벽한 방법입니다. 이들은 Agile 사고 방식의 일부이며 공유된 이해를 구축하기 위해 요구 사항에 대해 이야기하기 시작하는 비공식적인 방법입니다. 기능에 대한 간략한 설명은 종이 카드(일반적으로 포스트잇 메모)에 작성되며 사용자 여정에 대한 설명을 만들기 위해 화이트보드에 섞여 있습니다. 사용자 스토리는 화이트보드의 참여, 토론 및 카드 조작을 통해 즉석에서 생성됩니다. 세부 사항은 천천히 구체화되고 마침내 제품 백로그의 기능으로 추가됩니다. Jeff Patton은 사용자 스토리 매핑에 대한 훌륭한 책을 저술했습니다. 이 책은 주제에 대해 더 알고 싶고 프로젝트에서 사용하기 시작하려는 경우 적극 권장합니다.

사용자 스토리는 한 번 만들어지면 영원히 잊혀지는 정적인 것이 아닙니다. 대신, 프로토타입 단계가 계속되고 제품이 형태를 갖추기 시작하면 개발 및 제품 팀이 계속해서 되돌아갈 수 있는 동적 맵입니다.

프로토타입의 중요성은 질문에 답하는 것입니다. 여러 프로토타이핑 방법론이 있지만 우리는 진화적인 방법론이 우리의 목적에 가장 적합하고 현대적인 애자일 소프트웨어 개발 파이프라인에 적용될 수 있다고 믿습니다. 진화적 프로토타입 방법론에서 프로세스는 순환적이며 프로토타입은 모든 주기를 통해 점진적으로 더 정교해집니다.

각 프로토타입 반복은 설계 단계에서 개발 및 평가 단계로 이동합니다. 그것은 초기 디자인 문제를 일으키고 사람들이 지적하고 개선할 수 있는 것에 대해 이야기할 수 있는 유형을 제공합니다. 평가 단계에서 수집 된 통찰력 은 다음 프로토타입 반복에 사용되며 주기가 다시 한 번 반복됩니다. 따라서 프로토타입은 완제품으로 성숙기에 도달할 때까지 최종 시스템으로 천천히 진화합니다.

프로토타이핑은 일반적으로 빠른 개발 속도로 이루어지며 Bedrock, Sage 및 Bootstrap과 같은 상용구 시스템을 사용하면 개발 시간을 크게 줄일 수 있습니다. 위에서 언급한 것과 같은 시스템은 완전한 애플리케이션 골격과 필요한 도구 모음을 제공하므로 매번 처음부터 시작할 필요가 없습니다. 진화형 프로토타입은 폐기 프로토타입과 동일하지 않습니다. 후자는 개념 증명으로 한 번만 제작된 후 폐기되는 프로토타입입니다. 전자 상거래 프로토타입을 만드는 데 상당한 시간을 할애한다면 모든 것을 버리고 0에서 시작하는 대신 공통 기능을 추상화하고 나중에 다시 사용하지 않겠습니까?

여기에서 Pressidium Cloning이 유용합니다. 클릭 한 번으로 웹사이트를 빠르게 복제하고 개발을 시작할 수 있습니다. 그렇게 하면 상용구를 사용하여 여러 템플릿 웹사이트를 준비하고, 필요한 플러그인, 테마 및 구성으로 미리 로드하고, 프로젝트에서 필요할 때마다 복제할 수 있습니다. 예를 들어 동일한 방식으로 클라이언트의 계정과 같은 다른 Pressidium 계정에 복제할 수도 있습니다. 프로토타입이 관리되는 다른 WordPress 호스팅 제공업체에 있는 경우에도 걱정하지 마십시오. 마이그레이션 마법사 도구를 사용하여 Pressidium 계정으로 가져오기만 하면 됩니다!

WordPress 프로젝트를 직접 개발하든 동료 WordPress 개발자 및 디자이너와 협력하든 상관없이 장기적으로 공예의 지속 가능성에 기여하는 가장 중요한 두 가지 사항은 다음과 같습니다.

1. 좋은 소프트웨어 습관을 들이십시오.
2. 그리고 모든 것이 무엇인지, 어디에 있는지, 왜 거기에 있는지 아는 것입니다.

모범 사례는 소프트웨어 스타일 가이드를 일관되게 따르는 것부터 영리한 대신 깨끗한 코드를 작성하는 연습, 높은 수준의 소프트웨어 및 UI 디자인 선택에 이르기까지 다양합니다. 두 번째 요점은 단순히 문서화이며 프로젝트 내에서 취할 수 있는 다양한 형식입니다.  

소프트웨어 스타일 가이드를 따르면 간단합니다. 문제에 대한 공식 WordPress.org 리소스를 연구한 다음 코딩 스타일에 포함할 수 있도록 어떤 지침이 의미가 있는지 결정하십시오. 습관을 바꾸는 것은 느린 과정이며 처음에는 작은 변화부터 시작해야 합니다. 궁극적으로 코드가 준수해야 하는 일련의 지침을 갖는다는 것은 어느 시점에서 코드 검토를 도입하는 것을 의미합니다.

코드 리뷰는 실수를 근절하고, 난해한 코드 부분을 설명하고, 코드가 표준 및 규칙을 준수하는지 확인하기 위해 코드를 읽고 검사하는 체계적인 방법입니다. 또한 자신이 아닌 팀의 다른 사람이 수행하는 것이 가장 좋습니다.

Pressidium으로 웹사이트 호스팅

60일 환불 보장

계획 보기

영리한 것보다 깨끗한 코드를 선호하는 것은 유감스럽게도 영리한 코드의 함정에 빠진 후에야 평가할 수 있는 소프트웨어 개발 "지혜의 진주"입니다. 요점은 다음과 같습니다. 어떤 경우에는 영리한 코드로 "해커" 점수를 얻고 등을 두드려주고 어떤 경우에는 성능을 향상시킬 수도 있지만 장기적으로는 궁극적으로 잃게 됩니다. "hackish"이고 읽기 어려운 코드는 미래에 이해할 수 없게 될 것입니다. 특히 파악하기 어려운 버그를 해결해야 하는 경우 비용이 발생할 수 있습니다. 최적화된 코드 작성과 깨끗한 코드 작성 사이의 균형을 찾는 것은 스스로 발견해야 하는 일이지만 깨끗한 면에서 실수하는 것이 항상 더 좋습니다.

또한 WordPress 사이트의 성능은 브라우저 캐시의 올바른 사용에 크게 의존하므로 관리되는 WordPress 호스팅 공급자가 캐싱을 사용하는 방법을 아는 것이 중요합니다. 그러면 코드가 호스팅 플랫폼과 시너지 효과를 발휘하여 최상의 성능을 얻을 수 있습니다. 그러나 올바른 방법으로 웹사이트의 속도를 측정하는 것은 생각만큼 쉽지 않으며 여러 문제가 포함되어 있다는 점을 명심하십시오!

따라서 높은 수준의 모범 사례에 대해 말하면 WordPress가 핵심 기능을 분리하고 REST API를 제공하게 된 결정은 확실히 그러한 사례의 예로 간주될 수 있습니다. 이 결정은 프로그래밍 방식의 콘텐츠 관리 시스템 및 "헤드리스" WordPress 애플리케이션 개발로의 새로운 시대로의 이동을 알렸습니다.

  우리는 WordPress REST API 에 대한 간략한 소개와 자습서를 작성했으며 Postman과 같은 브라우저 플러그인을 사용하여 간단한 방법으로 땜질을 시작했습니다.

  이 소프트웨어 설계 결정은 믿을 수 없을 정도로 단순하면서도 강력했습니다. WordPress 개발자는 이제 WordPress를 사용하여 웹사이트나 블로그를 훨씬 능가하는 애플리케이션과 기능을 구현할 수 있습니다. 특히 적절한 예는 Kanban 프로토타입입니다.

카테고리 및 게시물과 같은 WordPress 엔터티를 사용하여 작업, 열 및 가치 흐름이 있는 Kanban 보드를 모델링했습니다. 우리는 모든 것을 하나로 묶는 Kanban Columns and Cards API를 스케치했습니다.

선적 서류 비치

누군가는 최고의 소프트웨어 관행이 단순한 코드 주석에서 프로젝트 결과물, 제품 카피에 이르기까지 더 나은 문서를 작성하는 데 도움이 된다고 주장할 것입니다.  

어떻게 보든 문서는 자산입니다.  

기술 문서에 관해서는 서면으로 사용하는 언어가 매일 의사 소통할 때 사용하는 언어 또는 직장에서 사용하는 언어와 확실히 다릅니다. 이러한 형태의 글쓰기를 기술적인 글쓰기라고 하며 컴퓨터나 소프트웨어 공학에서만 사용되는 것은 아닙니다. 사실, 그것은 법률, 의학, 항공 등과 같은 전문 청중에게 기술적 개념을 전달해야 하는 모든 직업에서 사용됩니다. 그것은 큰 주제이며 기술 작문 인증을 제공하는 대학도 있습니다. 그것의 존재 이유는 명확하고 간결한 언어를 사용하여 기술 정보를 전달하는 것입니다. 능동태는 수동태보다 선호되며, 수동태는 개념을 설명하기 위해 설명 텍스트가 필요한 경우에 사용됩니다.

기술 작가는 독자가 특정 정보를 검색하는 동안 종종 좌절하는 사람이라는 점을 염두에 두어야 합니다. 결과적으로, 당신의 글이 방해가 되지 않아야 합니다. 목표는 이 과정을 쉽고 간단하고 즐겁게 만드는 것입니다!  

학위가 있거나 전문 기술 작가가 될 필요는 없지만 개념을 간결하고 간단한 방식으로 전달하는 방법을 아는 것은 WordPress 개발자로서의 경력에 ​​매우 중요합니다. 따라서 플러그인, 테마 또는 자신이 구축한(자랑스러운!) API에 대한 문서를 작성해야 할 때마다 기본 사항을 숙지해야 합니다. 이러한 이유로 우리는 WordPress 플러그인 및 테마 문서화에 대한 빠른 가이드를 작성했으며 기술 작성의 5가지 기본 원칙도 다룹니다.

그러나 문서화는 여기서 그치지 않습니다. 테마 또는 플러그인이 더 큰 프로젝트의 일부이거나 자체적으로 충분히 복잡한 경우 제품 문서의 관점에서 생각하기 시작해야 합니다. 문서가 자산이라는 사실에 덧붙여 제품 문서도 마케팅 자산입니다. 이는 제품 문서의 중요성에 대한 Mashable 기사에서 MindTouch의 마케팅 부사장 Mike PuterBaugh의 다음 인용문에 적절하게 요약되어 있습니다.

그것은 섹시한 사업은 아니지만 동료의 존경을 받고 보다 효과적인 회사 관리 및 보다 협력적인 팀을 얻을 수 있습니다. 이번 분기나 올해가 아니라 경쟁 우위와 장기적 성장에 영향을 미치기 때문입니다.

제품에 관해서 는 가장 일반적인 형태의 문서 문서 외에도 온라인 도움말, 스타일 가이드, 마이크로컨텐츠 등과 같은 몇 가지가 더 있습니다. 제품 문서는 일반적으로 여러 사람들이 공동으로 작성하므로 복잡성이 가중됩니다. 이러한 방식으로 생각하고 계획하는 데 도움이 되는 광범위한 가이드를 작성했습니다.

마지막으로 프로세스의 마지막 단계인 배포로 넘어가면서 문서 퍼즐의 마지막 조각인 배포 다이어그램을 배치합니다. 이것들은 모든 것이 무엇이며 어디에 있어야 하는지에 대한 명확하고 구체적인 아이디어를 갖는 데 도움이 됩니다.

  대부분의 사람들은 UML에 대해 듣고 공포에 질려 비명을 지르며 도망칠 것이지만(물론 UML의 전체 사양은 형편없다) 이를 옹호하기 위해 UML에는 프로젝트에 가치를 추가할 수 있는 표기법 도구의 하위 집합이 포함되어 있습니다. 배치 다이어그램은 노드와 통신 경로로 구성된 놀라울 정도로 간단한 표기법으로 프로젝트에 존재하는 다양한 환경과 모든 구성 요소를 배치해야 하는 위치를 한 눈에 볼 수 있습니다.

앞으로 UML, 특히 시퀀스 다이어그램이라고 하는 또 다른 유용한 표기법과 프로젝트 요구 사항을 구체화하고 프로토타입을 구축하기 위한 사용 사례 시나리오 다이어그램의 보다 자세한 예에 대해 더 자세히 알아볼 것입니다.

대부분의 최신 개발 및 배포는 git 및 SVN과 같은 버전 제어 형식을 사용합니다. 소스 코드 리포지토리는 혼자만의 워드프레스 개발자라도 그 이점이 광범위하기 때문에 팀에만 필수적인 것이 아닙니다.

Pressidium 클라이언트인 경우 deploybot과 같은 외부 서비스를 사용하여 SFTP를 통해 리포지토리를 계정과 통합할 수 있습니다. 또는 SFTP를 사용하여 파일을 계정으로 전송할 수 있습니다. 이것이 가장 쉽고 간단한 방법입니다. 여러 SFTP 사용자를 생성하여 특정 웹사이트 및 환경에 할당할 수도 있습니다. 말하자면 웹 사이트를 위한 스테이징 환경이 있으면 개발 및 배포 프로세스가 보다 간소화되고 프로덕션 웹 사이트가 원치 않는 변경으로부터 안전하게 유지됩니다. 예를 들어 웹 사이트에 대해 스테이징을 활성화한 경우 프로덕션에서 복사본을 가져온 다음 스테이징 환경에서만 액세스할 수 있는 개발자용 SFTP 계정을 만들 수 있습니다.

여러 환경을 통과하는 간소화된 개발 파이프라인을 설정하는 것은 DevOps 운동이 IT 환경에 가져온 변화 중 하나입니다. 지속적 전달 원칙을 채택하고 소프트웨어 변경 사항을 점진적으로 자주 푸시하면 배포 주기가 빨라지고 오류가 줄어듭니다. 더 이상 다른 버전의 애플리케이션으로 ZIP 아카이브를 유지 관리할 필요가 없습니다. 그렇게 하면 쉽게 추적을 잃고 프로덕션 시스템에 해를 끼칠 수 있는 잘못된 변경 집합을 배포할 수 있습니다. 또한 파일 권한이 손상되는 문제가 발생하여 응용 프로그램이 제대로 작동하지 않고 최악의 경우 보안 문제가 발생할 수 있는 위험이 있었습니다.

발문

WordPress 개발자로서의 자유 시간은 매우 제한적입니다. 이것이 정보 과부하가 실제이고 WordPress 개발자뿐만 아니라 모든 지식 근로자에게 영향을 미치는 것처럼 보이기 때문에 단일 문서에 모든 것을 통합한 이유입니다. 처음에 우리의 목표는 유용한 정보를 제공하는 것이고, 두 번째는 현재 WordPress 문헌에서 제대로 표현되지 않는다고 생각되는 주제를 해결하는 것이라고 언급했습니다. WordPress 개발자가 되는 것과 관련성을 유지하는 것, 경쟁력을 유지 하는 것은 별개입니다. 그렇게 하려면 소프트웨어 엔지니어링을 하나의 학문으로 잘 이해하고 장기적으로 경력에 도움이 될 좋은 습관, 방법론 및 기술을 습득해야 합니다.