新しいプラグインのピアレビューを取得していますか？

経験豊富なWordPress開発者が私のプラグインを見て、建設的な批判をするための最良の方法は何ですか？私はこのサイトで私の質問のいくつかを解決するためのコードを書きましたが、それらは他の人にも役立つと思います。しかし、彼らは私の最初のパブリックWordPressプラグインを使用し、パブリックWordPressディレクトリにそれほど大きくない例を多く見たので、「私が立っている場所」と、プラグインを改善する方法を知りたいのです。ベストプラクティスのリストを読みましたが、それらの一部を適用する必要がありますが、「これはこの問題を解決するのに良い方法ですか？」というより一般的な質問への回答も必要です。

私は関連する議論をwp-hackers読み直しました（参加者もこのサイトにそれほど関与していること、および「ベストプラクティス」の質問がその直接の結果であることを知りませんでした）。私のニーズがそのようなシステムでカバーされるかどうかはわかりませんが、ポールの懸念に同意します。

先週このスレッドの元のコメントを読んだとき、目的は、プラグイン開発者が他のプラグイン開発者にコードのレビューとしてアドバイスを提供できるピアレビュープロセスをまとめることでした。私はもともとこのアドバイスを「まあ、あなたのコードは機能しますが、このWPフィルターにフックしてこの手法を試しただけの場合、記述した一連のルーチンのほうが効果的です（例としてxxxプラグインを参照）。 」私が思った目標は、WPプラグイン開発の知識を共有し、平凡なプラグイン開発者をより優れた開発者にすることでした。私のように。

これは、ポイントごとのチェックリストのレビューを行うのとは異なるスコープであり、「メンターシップ」のようなものです。これをやろうとする人はたくさんいるようで、このサイトには（もっと良いことに）多くの人が参加しています。そのエネルギーをすべて具体的なものに変換するにはどうすればよいでしょうか。

私の現在の例は、「イメージのサイズ変更」問題を解決するために書いた3つのプラグインです。各プラグインに長い紹介コメントを書いたので、コード全体を読まなくても、自分の意図を理解しやすくなります（私はそう思います）。他の人が見やすくするために他にできることはありますか？ 現在の具体的なリクエストは無視してください。彼らにとって早すぎるだけでなく、気が変わって、私の特定の状況で一般的な議論を台無しにしたくありません。

最も簡単な方法は、2ステップのアプローチです。

1. プラグインを公開します。 公開されると、開発者だけでなくエンドユーザーからのフィードバックが得られます。必要に応じて、「ベータ版」バージョンとしてリリースし、readmeファイルでそのことを強調します。
2. 聞いてください。 どこにでもベテランのWordPress開発者がいます：ここ、WP-Hackersリスト、WordPressの求人、Twitterで@wordpressをストーキングするなどです。プラグインをそこに捨ててフィードバックを求めるだけの問題です。

一般に、開発者がコアパッチを確認するのと同じ手順に従います。

• 書いてください
• 文書化する
• 開発者に連絡し（上記のチャネルのいずれかを介して、または可能であれば直接）、フィードバックを依頼します。

このサイトで発生する一種の「メンターシップ」をより具体的なものに変換する限り、それは有機的なプロセスでしょう。すでに述べたように、実際に何かをレビューする前に、ある種のプラグインレビュープロセスを作成しようとすると、行き詰まったようです。何かを実現する唯一の方法は、実際にそれを始めることです。ですから、ベテランの開発者を見つけてフィードバックを得ることについて話すだけでなく、出て行って見つけ、フィードバックを得て、プロセスがどのように進んだかを書き留めてください。

その後、将来のプラグインと将来の開発者で繰り返すことができます。しかし、あなたはどこかから始めなければなりません...

ざっと見た後https://gist.github.com/675437私は主に読みやすさについては、いくつかのマイナーなポイントを見ました：

• 優れたコードドキュメントを作成する：Docblocks…何かが完全に明確でない場合は、インラインコメント
• looong関数をより短い個別の関数に分割します。それらは読みやすく、レビューアのコメントで対処するのが簡単です。
• 割り当て演算子を揃え、括弧の間に空白を追加します。
• 行の長さは80文字にしてください。Eclipseはまだ長い行をラップできません。:(
• コードを「残して」、インデントを保存します。の代わりに：

。  

public function checkUrl()
{
    if (is_404()) {
        // code
    }
}

… 書く …

public function checkUrl()
{
    if ( ! is_404() ) {
        return;
    }
    // code
}

今夜、私は新しいプラグインを書きました…そしてあなたの質問を正確に尋ねるかもしれません。良いタイミング。:)

それはちょうど私がAppScanのを考えさせられた。http://www01.ibm.com/software/rational/products/appscan/source/。http://www-01.ibm.com/software/rational/products/appscan/source/features/試用版の軽量バージョン：http : //www-01.ibm.com/software/awdtools/appscan/express/

これはphpを実行することができ、そこに追加のルールを置いてチェックすることができます。このようにして、（toschoからの回答のようないくつかのベストプラクティスのように）パーツを自動化し、セキュリティ、コーディング標準、最適化などをチェックできます。

私が言っているのは、ツールが80％をチェックできる場合、20％のチェックでグルの手動チェックが少なくなるということです。また、追加のコードに関してこのようなことを要求する大企業内でプラグインを使用するためのコンプライアンスレポートを生成するのにも役立ちます。

私たちは他の人のために物事を自動化するので、なぜ私たち自身のためではないのですか？