PHPと型〜型宣言 (タイプヒンティング)を活用しよう〜

ササテンです。こんにちは!
久々にPHPと本気で向き合ってみようと思いまして、記事を書いてみます。

いきなりですが、皆様はPHPに対してどのような印象をお持ちでしょうか?

PHPは柔軟な言語です。生き物に例えるならばタコのように柔軟であり、変数を柔軟に解釈してプログラムを実行していきます。このように柔軟な言語は、PHPのみならずPerl・Ruby・Pythonを始めとしたLL言語(軽量プログラミング言語)に多く、主にWEBシステムを開発するための言語として、型を明示的に宣言しないスタイルが流行しました。

一方で、近年登場した言語の多くは、型を宣言するスタイルをとっています。Go・Swift・Kotlin・TypeScript(AltJS)を始め、たくさんの言語が思いつくことでしょう。型を宣言するスタイルは、変数に制約を設けることができるため、品質を落としにくいという利点があります。

PHPにも流れにのって型宣言(タイプヒンティング)が登場しましたが、型宣言を使わなくてもプログラムが書けてしまうため、いまいち知られていないという印象があります。PHPで型宣言を活用するには、一工夫が必要になりますので、ここで一つ紹介していきます。

PHPの型宣言を利用するにはPHP7が必要である

PHPで型宣言を利用するには、基本的にPHP5.4以上である必要があります。ただし、PHP5.4の型宣言は不完全であるため、実質はPHP7.0以上の機能であるといえるでしょう。

PHPの型宣言は関数に定義する

PHPの型宣言は、変数宣言に定義するのではなく、関数の引数と戻り値に対して定義します(なお、通常の変数に型宣言を定義する方法は、私が知る限りはなさそうです)。

test関数の引数と戻り値の定義に注目してください。これは「intとstringを受け取り、boolを返す関数ですよ」ということを示しています。ここで重要なことは「PHPで型宣言を活用するためには関数を多用したプログラミングが必要である」という点です。

// intとstringを受け取り、boolを返す関数です
function test(int $num, string $str): bool
{
     // 関数のコードを書く(返却値はboolでなければならない)
     return true;
}

UNIX思想でプログラミングしよう

「UNIXという考え方 その設計思想と哲学」という Mike Gancarz の名著をご存知でしょうか?

UNIX思想には、以下の二つの定理があります。

・定理1 スモール・イズ・ビューティフル
・定理2 1つのプログラムには1つのことをうまくやらせる

PHPで型宣言を活用して品質の良いコードを書くためには、関数化が必要であると先程述べました。なぜUNIX思想を紹介したのかと申しますと、UNIX思想はPHPの型宣言スタイルと相性が良いのです。

つまり、UNIX思想の一つである様々なUNIXコマンドのパイプラインのごとく、細かい関数を組み合わせることによって、一つのPHPプログラムを組み立てていくのです。そうすれば、型宣言をフルに活用することができます。

なお、このスタイルを採用するとどうしても関数が増えてしまいます。関数はある程度の単位でクラス化し、静的関数としてまとめて書いていきましょう。静的関数は状態を持たないので、ユニットテストがやりやすいというメリットもありますしね。

final class Abc
{
    static function def(string $aaa, string $bbb): bool
    {
        // 関数のコードを書く
        // 真偽値を必ず返す
    }

    // ?int は、 NULLもしくはintを返すという意味です。
    static function ghi(string $aaa, string $bbb): ?int
    {
        // 関数のコードを書く
        // NULLもしくは整数を返す
    }
}

まとめ

PHPは、型宣言にマッチしない変数が与えられると、エラーを出力します。

例えば、数値しか想定しないような会員番号であったり、金額といった変数は、intで型宣言を定義するようにしましょう。万が一、金額に文字列が与えられたとしても、エラーの出力によって発生にすぐ気づくことができます。

また、型宣言を活用すると、新人エンジニアも変数の型を意識するようになるというメリットがあります。私は、型の知識やノウハウはC言語で得ましたが、現在使っている言語で学べるのであれば、それに越したことはありません。

ぜひともPHPの型宣言を活用して、品質の良いPHPプログラムを目指していきましょう!

【オガティ外伝】オフショア開発の巻 in ベトナム(オフショアの課題編)

今回が本当に最後になります。ベトナムオフショア開発の最後のお話です。
はりきっていきましょう!
永遠の輝き、リモートワーカーのコウダインテだよ!シンチャオ!

12月ですね。諸説ありますが、師走というのは「師匠が走り回るくらい忙しい時期」と言われています。
あなたは師匠といい関係を築いていますか?
余計なお世話ですね。
では、クリスマスのご予定は?
余計なお世話ですね。

そんなことは置いといて、前後編に分けて「オフショア開発をするにあたって」「ベトナムでの生活」など、開発とプライベートについて記事にしてきましたが、2回に分けても書ききれなかった「オフショア開発の効果」について紹介します。
あまり芳しい結果を得られなかった今回のオフショア開発でしたが、その原因とそもそもの「オフショア開発」についてスポットを当てて紹介するナムよ。


<続きを読む>

【オガティ外伝】オフショア開発の巻 in ベトナム(後編)

前回に引き続き、コウダインテです。シンチャオ!(ベトナム語使ってみた)

1週間が経ちましたが、みなさん何かいいことありましたか?
私は特にこれといって何もありません。11月に入り、北海道は一気に気温が下がってきて、最近では0℃前後が続いておりとても寒いです。
雪が降っている地域もありますので、雪国の方は早めに冬タイヤへお取り替えください。

さあ、年末が近づいて忙しくなっているみなさま。
忙しさに心まで荒んでませんか?部下に理不尽なこと言ってませんか?
上司に理不尽な要求していませんか?上司に何でも払わせてませんか?
私は払わせ、いや払って頂いてますよ!!

そんな方も、そうではない方も、今回の記事で心を癒やしてください。
前回とは変わって、オガティのプライベートにスポットを当て、ベトナムでの生活事情、オガティの休日、最後には今回のオフショア開発で感じたベトナムの魅力について紹介します。
前回に引きつづき読んでいただいている方、本当にありがとうございます。

それでは、「【オガティ外伝】オフショア開発の巻 in ベトナム(後編)」はじまるよ~


<続きを読む>

【オガティ外伝】オフショア開発の巻 in ベトナム(前編)

ねえ、オガティ。こっち向いて。
で、お馴染みのリモートワーカー・コウダインテだよー。

今回は今までと毛色が変わりまして、直接的な開発の話ではなく
2015年にオガティが携わったオフショア開発にまつわるエトセトラを前後編に分けて紹介していきます。

オガティのプロフィール

オガティー

2014年3月から現職。当社のベンチャービジネスに心惹かれて入社。 それ以前はソフトハウス(2社)に在籍。 エンジニア歴はもう少しで20年。通信キャリアーのシステム開発、サーバーサイドプログラミングの経験が長い。 エンジニアとしてのベースはJava屋。Androidアプリ開発も。サーバーサイドはPHP, Node.jsが多い。 フロントエンドエンジニアとしては駆け出し。

趣味:ギター、ドラム、フットサル、お酒

<続きを読む>

性能テスト、性能改善に関するお話し

こんにちは、エンジニアの尾形です。

今回は、Webシステムの性能テストについて、テストの実施、改善までの流れを紹介させていただきます。

まずはじめに、システムの性能とは何でしょうか。簡単に言うと「何らかの要求に対する結果を返す力」のことです。

性能に対する考慮が不十分であったり漏れていたりすると、問題が発生する場合があります。
次のようなケースは実際に体験したり聞いたりしたことがあるのではないかと思います。

・チケットの予約サイトに受け付け開始直後にアクセスしたらつながらない
・テレビで放映されたお店のサイトに放映直後にアクセスしたらつながらない

これらの事象は、サイトへのアクセスが殺到したことによりサーバーの限界を超えてしまい、正常に処理が行えなくなったと推測できます。

システムの性能はシステム開発における重要な要素のひとつです。
性能テストって何?といった方や、性能テストを行ないたいが何をすればよいのかわからない、といったような方の参考になれば幸いです。

<続きを読む>

「INDEXによる高速化」は本当なのか!?PostgreSQLでパフォーマンスチューニングしてみた

お久しぶりですね。
みんなの恋人(ラバー)、リモートワーカーの仲井です。

カタリストで作っている「とある魔術系のサイト」では、それなりに魔力(規模)が大きいためにどうしても詠唱(検索処理)が遅くなってしまうことがありました。
テーブルによっては1000万超のスペル(レコード)もあり、高名なハイウィザードでもないかぎり、ここの詠唱(検索処理)がボトルネックになることも多いです。

ちょっとひねって面白くしようと思ったけど、上司のウケも悪いし、続けるのもめんどくさいからこの魔術設定はやめますね。

(大規模サイト担当してる人から見ればたった1000万でしょ? となるかもですが、カタリストでは大きい方なのです。というかビッグデータを扱うサービスと比較するのは用途もスペックも違うんだしナンセンスですね。)

ここまで大きくなくても、数千、数万レベルのレコード数であっても設計を間違えるとそれがボトルネックになることもあり、必ずしも大容量データだと遅くなるというわけではありません。大容量でも適切なチューニングがされていれば問題はないのです。

DBのパフォーマンスチューニングについてはたくさんのサイトやブログで紹介があり、皆さま既に知識としてはご存知とは思いますので、細かい内容は無視して「チューニングすると、実際これくらい差が出る」ということを、私がこれまで経験した内容を紹介したいと思います。

<続きを読む>

ユニットテストを書こう (TypeScript版)

こんにちは、エンジニアの尾形です。

みなさん、ユニットテストを書いていますか?
このページに訪れた方は、少なくともユニットテストに興味がある方でしょう。

今回のブログでは、ユニットテストの流れをサンプルプログラムとともに簡単にご紹介します。
これからユニットテストを始めたいという方の参考になれば幸いです。

今回のサンプルプログラムはTypeScriptで記述していますが、
Node.jsやその他の言語でも考え方はほぼ同じです。

<続きを読む>