レガシーズ 公式ブログ

レガシーコードと戦い続ける謎の集団、レガシーズの公式ブログです。 ※レガシーズはレガシーコードを通じて正しいコードの構造や改善の手法を模索する覆面集団です。特定のプロダクトやサービスを誹謗中傷する事が目的ではありません。

[mask-legacy]

PHPerはSpikaのどこを見たのか？

みなさん、こんにちは。マスク・ド・レガシーです。 PHPカンファレンスも無事に終わり、ゆっくりと休暇を楽しんでいたところ、にわかにタイムラインが騒がしくなっていました。今回は話題の中心になったSpikaを題材にPHPのコーディングについて考えてみようと思います。

Spikaの概要

SpikaはMITライセンス化のオープンソースとして公開されたメッセンジャーアプリケーションです。プロジェクトにはネイティブで実装されたiOS、Android向けのモバイルアプリケーションとPHPで実装されたサーバーサイドを組み合わせる事で独自のメッセンジャーサービスを構築する事ができます。 メディアの記事ではバックエンドはCouchDBとの事でしたが、プッシュ通知を管理する為のキューと管理画面にMySQLも利用されています。インストーラーによると動作条件は下記の通りです。

PHP 5.0 or higher

MySQL 4.0 or higher

Linux (not necessary but you probably should to change code)

Permission to run command from PHP

バックエンドは管理画面を除くとJSONを返却するだけの非常に薄いアプリケーションになっており、ユーザーインターフェースの実装はモバイルアプリ側に委ねられています。

PHPerが気にした点

では公開されたソースコードを見た際にPHPerがどのようなポイントに目を止めて、話題にしたのかを見てみましょう。

ライブラリ、フレームワークの使用の有無 まずソースコードを見て見るのが利用しているフレームワークやライブラリが何なのかという事でしょう。アプリケーションを実装する際に頻繁に利用されるデータベースの処理やパラメータのハンドリング、ロギングなどさまざまな処理を実装せずに済みます。またソースコードの大まかなフォーマットや体裁が決まる事で独自ルールのソースコードを発展させずに済みます。Spikaについてはメール送信のqdmailを除くとフレームワークやライブラリが一切利用されておらず、必要な処理を充分なレベルで実装するのには大きな労力が必要になると予想されます。

オブジェクト指向機能の活用 次に気になるのがオブジェクトの設計や例外、オートロードといった機能の活用度合いです。より新しいPHPにはより多くの機能が備わっており、活用する事でソースコードをより簡潔に記述する事ができます。またクラスベースの設計にする事でユニットテストを実行しやすいソースコードにできる点も非常に重要です。Spikaについては全て関数ベースでの設計となっており、コードの再利用性やユニットテストのしやすさに課題があります。

グローバル変数の撤廃 次に気になるのがグローバル変数を利用したコーディングを減らす事です。クラスを採用しなかった事関係でパラメーターとして引きまわす事ができなかった変数をグローバル変数として利用するコードが多く見受けられます。グローバル変数を使うことで関数のスコープが破壊され、コードのメンテナンスが難しくなります。また$_GETのようなスーパーグローバル変数を直接参照する事も良い方法ではありません。Spikaではまたリクエストのボディ部分などを扱う必要もあり、その部分については個別の実装が行われています。

入出力部分の処理 データベースへのクエリの組み立てや画面の出力など、入出力は脆弱性を作りこみやすいポイントです。Spikaについてはデータベースへの接続にmysql_queryやcurlなどを使ったベタな実装をしている点が多くコードの重複や文字列でのクエリの組み立てなどの問題が見受けられます。また画面数が多くない事もHTMLについては古典的な埋込み型の記述が見受けられます。

コードのフォーマット こちらは本質的な事ではありませんが、インデントやコードのスタイルなどがあまり一般的な形式になっておらず、一見した際にレガシーコード感を醸し出しています。とはいえ近年はIDEなどが発達したこともあり、この問題は目立つようであまりに問題ではないでしょう。

上記のような点が一部話題を呼んでいた点であると言えるでしょう。とはいえ実際にコードを動かしてみた人はごくわずかと思われますので、多くの場合は目につきやすい入出力の処理やコードのスタイルなどについて言及しているのではないでしょうか。

今後の対応

ではSpikaのコードがどのように修正されていくべきかについての案をいくつか示しておきます。

ライブラリ・フレームワークの利用 外部のライブラリを利用する事でデータベースに関する処理やパラメーターなどのリクエスト情報のハンドリング、ロギングなどの完成度が飛躍的に高まります。特にSpikaのプロジェクトはAPIが多いことからリクエストのハンドリングは必須であるにも関わらず、ベタな実装になっています。ライブラリの導入はもちろんComposerを使うのが良いでしょう。

ユニットテストの導入 こちらレガシーコードを改善する為には欠かすことのできないものです。とはいえクラスベースの設計になっていない事や、設定方法などが簡素化されていない点などがあり、テストスイートの構築には技術的な問題が多くあります。多少の離れ業を使ったとしてもテストの自動化だけは欠かすことが出来ない点でしょう。

設定ファイルとソースコードの分離 これは実際に動作させてみてわかる点ですが、インストーラーを実行後にソースコードの書き換えが必要になる部分があります。ソースコードの手動での書き換えはデプロイやテストの自動化の妨げになります。動作上必要な設定項目を分離し、扱いやすい構造にする必要も大きいでしょう。

※レガシーズはレガシーコードを通じて正しいコードの構造や改善の手法を模索する覆面集団です。特定のプロダクトやサービスを誹謗中傷する事が目的ではありません。

[mask-legacy]

活動報告 「レガシーコード in WordPress」 #phpcon2013 #wctokyo

Photo from Dj-Kaz.com

レガシーコード In WordPress from mask_legacy

こんにちは、マスク・ド・レガシーです。幅広いユーザーに愛されているCMS、WordPressですが大きなユーザーベースと引き換えに後方互換性やプラグイン開発者を守る為にレガシーコード的な兆候が幾つか現れています。今回の資料で指摘した点については数年前から修正のパッチやチケット上での議論は行われています。

バグ報告や機能要望が行われるTrac上を見ると機能に関する山のようなチケットが存在しており、そうした要望へのキャッチアップやレスポンシブ対応などのUI/UXに多大な努力を払っていることは驚きを禁じえません。

後方互換性を保ちながら、コードをリファクタリングする活動や、GitHubを使った開発、PSRへの参加とComposerの対応で外部のライブラリを積極的に利用するなどの変化が起こる事を期待しています。

一見、遠回りにも見えるかもしれません。ですがその他のCMSやフレームワーク、ライブラリなどが活用しているツールやプラクティスを取り入れる事は長期的にはコアの機能のスリム化による開発効率のアップなどWordPressの更なる発展に寄与するでしょう。数年に渡る議論が行われている事を考えると、WordPress4などのメジャーバージョンアップの際にそのような変更が予定されているのかもしれません。

※レガシーズはレガシーコードを通じて正しいコードの構造や改善の手法を模索する覆面集団です。特定のプロダクトやサービスを誹謗中傷する事が目的ではありません。