PhpStormでWordPress開発するときの補足

先日WordBench東京で「まだエディタで消耗してるの？PhpStormではじめる異次元のWordPress開発」という発表を行ったのですが、そのときデモでやっていたことの補足です。

コード補完についての補足

実演してみたときはわりと「はあ……」という反応が多かったのですが、コード解析の対象の広さがPhpStormの魅力の一つです。僕もわりと経験を長く積んでいるので、「このコードが動きません、助けてください」といって直してあげることがあるのですが、そういうときにどうでもいいタイポやなんかで動かなくなっているのを見つけると、凄まじい徒労感に襲われます。

コード補完については少しでも質の高いものを使ってください。時間の節約になります。

その1. 自分で作ったフックでもヒントに出てくる

上の画像の通り、Ginanismというプラグインで作ったフックもコード補完の対象になっています。当然、コアに含まれないプラグインやテーマも同様なので、WooCommerceサイトでStoreFrontの子テーマを作るときや、他人の作ったプラグインに機能追加するときに超絶役立ちます。これができるIDEはたぶんPhpStormだけだと思われます。

その2. Angularもコード補完の対象

これが他のIDEでできるかどうか知りませんが、JetBrainsのIDEはどれもAngularをサポートしているので、ディレクティブやコントローラーを追加するとそれが補完対象になります。コントローラーメソッドも同様。

ポイントは、「他人が書いたコードも同様」ということですね。これは超デカイですよ。他人が書いたディレクティブの名前なんて、いちいち覚えてないじゃないですか。

Reactに対応しているかどうかはわからないのですが、JSのコード補完についてもJetBrainsは頭一つ抜きん出ている印象です。昔もそんな記事（PhpStorm+MooToolsでオブジェクト指向のJavascript開発）を書いてますね。

その3. Pharファイルの中身も解析対象

Pharはあんまり使わないかもしれませんが、WordPressにおいてはWP-CLIがPharパッケージです。コマンドファイルをExternal Folderに追加しておくと、WP-CLIの補完が利くようになります。

その4. SASSの変数も解析対象

一応、SASSの変数も解析してくれます。Font-Awesomeもnpmとかでローカルに落としておけば、「fa-chevronだっけ、fa-arrowだっけ」という悩みが減ります。

あと、個人的にはCSSの色名の横にカラーピッカーが出るの、最高だと思います。Atomとかもそうだとは思いますが。

プログラミング補助ツールについての補足

以下に挙げるツールはNetBeansやEclipseなどのIDEでも対応しているとは思いますが、「こんなことできるよ」という補足として、念のため。

その1. ユニットテスト

たとえば、添付画像のようにPHPUnitによるテストも走らせることができます。コミット前にテストするときなんか、わりと便利です。僕は使っていませんが、Behatなども連携可能です。

WordPressにおけるユニットテストのやり方はちょっと特殊なので、和歌山県在住のWordPressに詳しい中年男性の記事を参考にしてください。

• WP-CLI+PHPUnitを使ったWordPressプラグインのユニットテスト（１） VCCWとか言われるので、ちょっとめんどくさい方法。
• WordPressプラグインのユニットテスト用のWordPress環境をセットアップする MAMPとか使ってる人はこっちがいいかも。

ユニットテストで難しいのは「テスタブルなコードを書けるか？」という点にありますので、それは適宜がんばってください。WordPressでPHPコードを書くというのは、ある意味草むらを縦横無尽に駆け回るようなものなので、完全にテスタブルなコードを書き続けられるなら、それは相当な実力者です。ぜひその秘訣をシェアして、コアにコミットしてください。

その2. コード品質管理

PHP Code Snifferのようなツールを使えば、書いている側から警告を発してくれます。設定画面で検索すると、設定項目が出てきます。他にPHP Mess Detectorなども対応しています。その名の通り、「クソコード検知器」ですね。

ちなみに、WordPressに関しては設定ファイルが公開されているので、そちらをインポートすることでWordPressコーディング規約に則ることができます。参考: PHP_CodeSniffer + WordPress-Coding-Standards をインストールする

面白いのはWordPress-VIPというコーディング規約で、これはAutomatticの提供するVIPサービスでのコーディングルールだと思うのですが、たとえば update_user_meta っていう関数を使うと、「個別にユーザーメタを保存するな、全部まとめて一つの配列にしろ」っていうアドバイスが出てくるんですね。これはなぜかというと、おそらくですが、ユーザーが膨大にいるサイトやマルチサイトの場合、ユーザーメタの総数が増えすぎてオブジェクトキャッシュが溢れちゃうからだと思います。よその会社のコードとか見る機会は滅多にないので、貴重な学習機会になりますね。

その3. ステップ実行

Xdebugを入れていれば、ステップ実行はできます。僕個人はJSやFlash以外でステップ実行の必要性をあまり感じたことがない（設定が面倒くさいわりにそんな使わない）のですが、必要ならできます。

WordPressの場合、エントリーポイントがindex.phpになるので、そこから辿っていってという感じですかね。

デプロイ、ソースコード管理など

コードを書くときではなく、コードを取り扱うツール類との連携も充実しています。

その1. Git

GitやSVNにも対応していますが、僕は使ってません。GithubのやつはGithub Desktop（プルリクがローカルでできるから）を使い、それ以外はSourceTree（プログラム書かない人との共通言語）で済ませてます。

その2. デプロイメント

SFTPにも対応しており、設定次第では「ファイルが更新されたらリモートにアップロード」なんてことも可能です。これに限らず、PhpStormには「ファイルウォッチャー」という機能があり、「ファイルが更新されたらなんかする」という設定ができます。が、僕は使っていません。

同日のセッションでWordMoveの紹介もありましたが、僕の場合はできればGithubにアップロードしたら自動デプロイになるようにし、それ以外のプロジェクトはTransmitの「同期」という機能で済ませています。

その3. タスクランナー

GulpやGruntを認識して、そのタスクを実行できるウィンドウが出せます。gulpのバイナリへのパスを通して置くことが必要です。

コンソール画面を開いておくことも可能ですが、僕は基本的にgulpが何をやっているかには興味はなく、エラーがあったときだけ知りたいので、gulp-notifyでデスクトップに通知を出すようにしています。

その4. ターミナル

ターミナルも一応ついています。ただ、プロジェクト開始時にnpmやcomposerを走らせる以外ではあまり使いません。GitやGulp、ユニットテストをIDEからできるようになると、触る機会もめっきり減ります。

サーバでの作業などはiTerm2を使っています。

日本語化について

日本語化プロジェクトは一応あります。

IDEA_Resource_JP

Githubも英語だし、英語のままでいいんじゃないの、と個人的には思います。

購入先

日本の代理店だとサムライズムさんが取り扱っているので、そちらから買えます。JetBrainsから直接買うこともできます。

まとめ

いままでIDEを色々使ってきましたが、最近はPCのスペックが上がったことで、どのIDEでもそんなに「重いなー」と思うことがなくなりました。

それよりは、コードの品質を高めるためにどれだけ知識を外部化できるかということに注力したいところです。JetBrainsのIDEは初期設定でもわりとお利口なので、プログラミングスキルが低い人ほど使った方がいいです。

モデレーターの清野くんとも話しましたが、 funciton とか書いてアップロードして構文エラーでサイトを真っ白にするような人ほど、IDEを使いましょう。終わり。