WordPress開発者：ここから始めましょう！

公開: 2017-10-14

WordPress開発者向けのスターターガイドへようこそ！ あなたがフリーランサーとして働いているか、メディアエージェンシーの一部として働いているかどうか。 この記事では、WordPressの開発に関連するさまざまなトピックと、利用可能なリソースとツールのいくつかについて説明します。
 テキストは、アイデアの生成と出荷の間を流れるさまざまな段階を中心に構成されています。 ブレーンストーミング、プロトタイピング、開発、そして最後に展開について説明します。 これらすべて、製品開発のコンテキスト内で。 私たちは、アイデアの最初のインクリングとその最終的な実行の間に、多くの微妙な領域があると信じています。 現在のWordPressの文献では、せいぜい議論されていないものもあれば、最悪の場合は完全に未踏のものもあります。  

Pressidiumクライアントの場合は、プラットフォームを中心に構築したツールの使用をすぐに開始できるため、高度な統合のメリットを享受できます。 これらのツールについても説明します。   これはライブドキュメントであり、そのように扱う必要があることを忘れないでください。

何よりもまず、このドキュメントがWordPress開発者としての実践に役立つこと、そして次に、私たちがあなたのために作成したいくつかのクールなものを紹介することです。

アイデアから展開まで 

新製品に取り組んでいる場合でも、クライアントの仕事を引き受けている場合でも、アイデアから展開に至るプロセスは4つの段階で構成されます。 これらのステージは離散的ですが、大幅にオーバーラップしており、線形ではありません。 これについては、テキストでさらに説明します。  

  1. ブレーンストーミングと要件の引き出し。
  2. プロトタイピング。
  3. 発達。
  4. 展開。
WordPress開発者：ブレーンストーミング

フリーアソシアティブブレーンストーミングのプロセスは、製品またはプロジェクトの構築を開始したいときにアイデアが必要な場合に使用されます。 ただし、要件の収集は、クライアント向けのプロジェクトを構築したり、ブレーンストーミングセッションの後にアイデアをまとめたりするタスクがある場合に発生します。 特定の問題を解決するために、後でブレーンストーミングセッションを設定することもできますが、それらのセッションはより制限されます。

ブレーンストーミングの基本原則は2つです。 量を求めて、後で判断するのを延期します。 私たちは過去に、そのようなセッションを促進する方法、適切な考え方を構築する方法、そしてあなたを助けるためのいくつかのファンキーなツールについて書いてきました。

要件を引き出す

要件を引き出すために使用される方法論はいくつかあり、従来、これは常にビジネスアナリストの仕事でした。 プロジェクトの要件に関する情報を提供するのはクライアントの責任ですが、すべての利害関係者に対して共通の理解を確立する必要があります。 要件の抽出は、要件の収集とは異なるプロセスです。 積極的に参加することで、必要な情報を引き出すことが重要です。 そして、それは、クライアントがあなたに話していることを受動的にドキュメントに集めて、それを開発チームに渡すことではありません。

プロジェクトの範囲と性質によっては、ユースケースは機能をキャプチャするための優れた方法です。 ユースケースは、システムの利害関係者とシステム自体の間の相互作用を記述する方法としてUML図で使用される手法です。 それらはプレーンで構造化された英語で書かれたシナリオのコレクションであるため、複雑さが軽減されるだけでなく、システム機能の説明とスケッチを開始するための迅速かつ効率的な方法です。

複雑な製品の要件を把握したい場合は、おそらくすべての利害関係者との構造化されたインタビューを設定する必要があります。 このため、ユーザーストーリーは最適な方法です。 それらはアジャイルの考え方の一部であり、共通の理解を構築するために、要件について話し始めるための非公式な方法です。 機能の簡単な説明は紙のカード（通常はポストイットノート）に書かれ、ユーザージャーニーのナレーションを作成するためにホワイトボードでシャッフルされます。 ユーザーストーリーは、ホワイトボード上のカードに参加し、話し合い、操作することで、その場で生成されます。 詳細はゆっくりと具体化され、最終的に製品バックログの機能として追加されます。 ジェフパットンは、ユーザーストーリーマッピングに関する優れた本を書いています。この本についてもっと知り、プロジェクトで使い始めたい場合は、この本を強くお勧めします。

ユーザーストーリーは、一度作成されると永遠に忘れられる静的なものではありません。 代わりに、それらは動的なマップであり、プロトタイピングの段階が続き、製品が形になり始めると、開発チームと製品チームが何度も戻ることができます。

WordPress開発者：プロトタイピング

プロトタイプの重要性は、質問に答えることです。 いくつかのプロトタイピング方法論がありますが、進化的な方法論が私たちの目的に最も適していると信じており、現代のアジャイルソフトウェア開発パイプラインに適応させることができます。 進化的プロトタイプ方法論では、プロセスは循環的であり、プロトタイプはすべてのサイクルを通じて徐々に洗練されていきます。

各プロトタイプの反復は、設計段階から開発および評価段階に移行します。 それは初期の設計問題を引き出し、人々が何を改善できるかを指摘し、話し合うことができる具体的な何かを提供します。 評価フェーズから収集された洞察は、次のプロトタイプの反復で使用され、サイクルがもう一度繰り返されます。 したがって、プロトタイプは、完成品として成熟するまで、ゆっくりと最終システムに進化します。

プロトタイピングは通常、急速な開発ペースで行われ、Bedrock、Sage、Bootstrapなどの定型システムを使用すると開発時間を大幅に短縮できます。 上記のようなシステムは、完全なアプリケーションスケルトンと必要なツールチェーンを提供するため、毎回最初から始める必要はありません。 進化型のプロトタイプは、使い捨てのプロトタイプと同じではありません。 後者は、概念実証として1回だけ作成され、その後破棄されるプロトタイプです。 eコマースのプロトタイプの作成にかなりの時間を費やしている場合は、すべてを捨ててゼロから始めるのではなく、共通の機能を抽象化して、将来再び使用してみませんか？

ここで、PressidiumCloningが役に立ちます。 ワンクリックでウェブサイトのクローンをすばやく作成し、開発を開始できます。 このようにして、ボイラープレートを使用して複数のテンプレートWebサイトを準備し、必要なプラグイン、テーマ、および構成を事前にロードして、プロジェクトで必要になるたびにクローンを作成できます。 同じ方法で、たとえばクライアントのアカウントなど、別のPressidiumアカウントにクローンを作成することもできます。 プロトタイプが別のマネージドWordPressホスティングプロバイダー上にある場合でも心配はいりません。 移行ウィザードツールを使用して、Pressidiumアカウントにインポートするだけです。

WordPress開発者：開発

自分でWordPressプロジェクトを開発する場合でも、他のWordPress開発者やデザイナーと協力する場合でも、長期的にクラフトの持続可能性に貢献する2つの最も重要なポイントは次のとおりです。

  1. 良いソフトウェアの習慣を実践する。
  2. そして、すべてが何であるか、それがどこにあるか、そしてなぜそこにあるのかを知ること。

ベストプラクティスは、ソフトウェアスタイルガイドに一貫して従うことから、賢い代わりにクリーンなコードを書くことを実践すること、そして高レベルのソフトウェアとUIデザインの選択に至るまでさまざまです。 2番目のポイントは、単にドキュメントであり、プロジェクト内でさまざまな形式をとることができます。  

ソフトウェアスタイルガイドに従うのは簡単です。 この問題に関する公式のWordPress.orgリソースを調べてから、コーディングスタイルに含めるためにどのガイドラインが意味をなすかを決定します。 習慣を変えるのは遅いプロセスであり、最初は小さな変更を加えることから始める必要があります。 最終的に、コードが順守する必要のある一連のガイドラインを持つことは、ある時点でコードレビューを導入することを意味します。

コードレビューは、コードを読んで調査する体系的な方法であり、間違いを根絶し、コードの厄介な部分を解明し、コードが標準や規則に準拠していることを確認します。 また、あなたではなく、チーム内の他の誰かが行うのが最善です。

Pressidiumであなたのウェブサイトをホストする

60日間の返金保証

私たちの計画を見る

巧妙なコードよりもクリーンなコードを好むのは、ソフトウェア開発の「知恵の真珠」であり、残念ながら、巧妙なコードの罠に陥った後にのみ評価することができます。 要点は次のとおりです。巧妙なコードによって「ハッカー」ポイントと背中のパットを獲得できる場合もありますが、場合によってはパフォーマンスが向上することもありますが、最終的には長期的には失うことになります。 「ハッキング」で読みにくいコードは、将来的に理解できなくなります。 また、特にとらえどころのないバグのトラブルシューティングが必要な場合は、コストがかかる可能性があります。 最適化されたコードとクリーンなコードの記述のバランスを見つけることは、自分で発見する必要があることですが、物事のクリーンな側面を誤ることは常に良いことです。

また、WordPressサイトのパフォーマンスは、ブラウザーキャッシュの正しい使用に大きく依存するため、マネージドWordPressホスティングプロバイダーがキャッシュをどのように使用するかを知ることが重要です。 その後、コードはホスティングプラットフォームと相乗的に機能し、可能な限り最高のパフォーマンスを発揮します。 ただし、Webサイトの速度を正しい方法で測定することは、思ったほど簡単ではなく、いくつかの落とし穴が含まれていることに注意してください。

したがって、高レベルのベストプラクティスについて言えば、WordPressのコア機能を切り離し、REST APIを提供することになった決定は、確かにそのようなプラクティスの例と見なすことができます。 この決定は、新しい時代、プログラマティックコンテンツ管理システム、および「ヘッドレス」WordPressアプリケーション開発への移行を示しました。

  WordPress REST APIの簡潔な紹介とチュートリアル、およびPostmanなどのブラウザープラグインを使用してWordPressRESTAPIをいじり始める簡単な方法を作成しました。

  このソフトウェア設計の決定は、一見シンプルでありながら強力でした。 WordPress開発者は、WordPressを使用して、Webサイトやブログをはるかに超えるアプリケーションと機能を実装できるようになりました。 特に適切な例の1つは、かんばんのプロトタイプです。

カテゴリや投稿などのWordPressエンティティを使用して、タスク、列、バリューストリームを含むかんばんボードをモデル化しました。 すべてを結び付けるかんばんの列とカードのAPIをスケッチしました。

ドキュメンテーション

ソフトウェアのベストプラクティスは、単純なコードコメントから、プロジェクトの成果物、そして製品のコピーに至るまで、より優れたドキュメントを作成するのに役立つと主張する人もいるかもしれません。  

どのように見ても、ドキュメントは資産です。  

技術文書に関しては、書面で使用される言語は、日常のコミュニケーションで使用する言語や職場で使用する言語とは明らかに異なります。 この形式のライティングはテクニカルライティングと呼ばれ、コンピューターやソフトウェアエンジニアリングでのみ使用されることはありません。 実際、法律、医学、航空学などの専門家に技術的概念を伝える必要のあるすべての職業で使用されています。 これは大きなテーマであり、テクニカルライティングの認定を提供している大学もあります。 その存在意義は、明確で簡潔な言葉を使用して技術情報を伝達することです。 能動態は受動態よりも好まれ、後者は概念を説明するために説明文が必要な場合に使用されます。

テクニカルライターは、読者が特定の情報を検索しているときにイライラすることが多い人であることを覚えておく必要があります。 結果として、あなたの文章は邪魔にならないようにする必要があります。 その目標は、このプロセスを簡単、簡単、さらには楽しいものにすることです。  

学位を取得したり、プロのテクニカルライターである必要はありませんが、WordPress開発者としてのキャリアにとって、概念を簡潔かつシンプルに伝える方法を知ることは非常に重要です。 したがって、作成した（そして誇りに思っている）プラグイン、テーマ、またはAPIのドキュメントを作成する必要があるときはいつでも、基本を理解する必要があります。 そのため、WordPressプラグインとテーマを文書化するためのクイックガイドを作成しました。このガイドには、テクニカルライティングの5つの基本原則も含まれています。

しかし、ドキュメントはそれだけではありません。 テーマまたはプラグインがより大きなプロジェクトの一部である場合、またはそれら自体が十分に複雑である場合は、製品ドキュメントの観点から考え始める必要があります。 ドキュメントが資産であるという真実に加えて、製品ドキュメントはマーケティング資産です。 これは、MindTouchのマーケティング担当副社長であるMike PuterBaughによる、製品ドキュメントの重要性に関するMashableの記事の次の引用に適切にカプセル化されています。

それはセクシーな仕事ではありませんが、それはあなたにあなたの仲間の尊敬、より効果的な会社の経営とより協力的なチームを獲得するでしょう。 それは今四半期や今年ではなく、競争上の優位性と長期的な成長に影響を与えることです。


 製品に関しては、最も一般的な形式の文書化されたドキュメントに加えて、オンラインヘルプ、スタイルガイド、マイクロコンテンツなど、さらにいくつかあります。 製品ドキュメントは通常、多くの異なる人々が共同で作成するため、複雑さが増します。 この方法で考え、計画を立てるのに役立つ広範なガイドを作成しました。

最後に、プロセスの最後の段階である配置にセグウェイするときに、ドキュメントパズルの最後のピースである配置図を配置します。 これらは、すべてが何であるか、そしてそれがどこにあるべきかについての明確で球形の考えを持つのに役立ちます。

  ほとんどの人はUMLについて聞いて恐怖で叫んで逃げますが（そして当然のことながら、UMLの完全な仕様はひどいです）、UMLには、プロジェクトに価値を付加できる表記ツールのサブセットが含まれています。 配置図は、ノードと通信パスだけで構成される驚くほど単純な表記法であり、プロジェクトに存在するさまざまな環境、およびすべてのコンポーネントを配置する必要がある場所を一目で確認できます。

今後、UMLについて、特にシーケンス図と呼ばれる別の便利な表記法や、プロジェクト要件を具体化し、プロトタイプを作成するためのユースケースシナリオ図のより詳細な例について詳しく説明します。

 

WordPress開発者：展開

すべてではないにしても、ほとんどの最新の開発とデプロイメントは、gitやSVNなどの何らかの形式のバージョン管理を利用しています。 ソースコードリポジトリは、チームだけでなく不可欠なだけではありません。WordPressの開発者が一人でも、そのメリットは非常に大きいからです。

Pressidiumクライアントの場合は、deploybotなどの外部サービスを使用して、SFTP経由でリポジトリをアカウントに統合できます。 または、SFTPを使用してファイルをアカウントに転送することもできます。これは、最も簡単で簡単な方法です。 複数のSFTPユーザーを作成し、それらを特定のWebサイトおよび環境に割り当てることもできます。 そういえば、Webサイトのステージング環境を用意することで、開発と展開のプロセスがより合理化され、本番Webサイトが不要な変更から安全に保たれます。 たとえば、Webサイトのステージングを有効にすると、本番環境からコピーをプルして、ステージング環境でのみアクセスできる開発者用のSFTPアカウントを作成できます。

複数の環境を通過する合理化された開発パイプラインのセットアップは、DevOpsの動きがIT環境にもたらした変更の1つです。 継続的デリバリーの規律を採用し、ソフトウェアの変更を段階的かつ頻繁にプッシュすることで、展開サイクルが短縮され、エラーが減少します。 アプリケーションの異なるバージョンでZIPアーカイブを維持する必要がなくなりました。 そうすれば、簡単に追跡できなくなり、本番システムに損害を与える可能性のある間違った一連の変更を展開する可能性があります。 また、ファイルのアクセス許可が破損するという問題が発生する危険性もありました。これにより、せいぜいアプリケーションが正しく機能せず、最悪の場合、セキュリティの問題が発生する可能性があります。

エピローグ

WordPress開発者としてのあなたの自由な時間はかなり限られていることを私たちは知っています。 情報過多は現実のものであり、WordPress開発者だけでなく、すべての知識労働者に影響を与えるように思われるため、すべてを1つのドキュメントに統合したのはそのためです。 私たちの目標は、最初に有用な情報を提供することであり、次に、現在のWordPressの文献では過小評価されていると思われるトピックに対処することであると最初に述べました。 WordPress開発者になることと、関連性を維持すること、そして競争力を維持することは別のことです。 そのためには、ソフトウェアエンジニアリングを専門分野として包括的に捉え、長期的にキャリアに役立つ良い習慣、方法論、技術を身に付ける必要があります。