PHPでRASIS四方山話

著:古庄道明氏

「変更容易性」を担保するための言語機能第04回 18年02月更新

変更容易性のお話が少し長くなっていますが、比較的多岐にわたるポイントとメリットがあるので、もう少しだけ続けていきたいと思います。

さて。
プログラムが「レゴブロックのようなものである」という比喩は、時々、使われているかと思います。
一方では「小さくて簡単なパーツを組み合わせると、複雑なものでも作成が出来る」といったニュアンスで、このあたりは「スモール・イズ・ビューティフル」や「一つのプログラムには一つのことをうまくやらせる」といった、いわゆるUNIXなどでよく出てくるお話になります(参考:UNIXという考え方)
もちろん、その一方で「適切なパーツを適切に選択する事のむずかしさ」というのもあるのですが。
ただ、選択を間違えなければ、「作って増築や再構築をして」、かなりすごいものでも作成ができます。Googleの画像検索で「レゴブロック 東大」などのキーワードで検索をすると、何割かの方にとっては「レゴといって想像するものから、少しかけ離れた作成物」の画像が見れるのではないか、と思います。

ただ他方で。
数多くのプログラムを見ていると、「増築や再構築」に耐えられないコード、というのがありまして。
そういったコードは、レゴというよりは「ジェンガ」というテーブルゲームに酷似しているように思われます。
問題のあるコードでも、大抵の場合は「作成直後の変更」には、なんとか、耐えられることが多いです。
ただ、変更をするごとに「負の遺産」とでも呼ぶべきものが蓄積されていき、段々と「同じような変更のはずなのに修正にかかる時間がどんどんと増加していく」ようになります。
この時間増加は青天井であるケースがほとんどなので、結果として「いつか、修正が事実上不可能に近くなる」瞬間が出てきます。
ただ、その時点で「作り直す」という選択肢を、費用面込みで取れるケースはあまり多くないので。結果的に「タワーがいつ崩れるかわからない」ジェンガと格闘する事になります。

また、近しいケースとして。
「似たような別のコード(例:一定期間だけ行うキャンペーン用のコード)」を、どんどんと「コピペで増産していく」ケースも、時々、見受けられます。
これらが「完全に租結合で切り離されている」のであれば、或いは、そういったアプローチも「なくはない」とは思うのですが(毎回、地味にかかるコピペからの微修正のコストが”どれくらい積みあがるか”にもよるのですが)。
一定の確率で「じゃぁ使っていないからコードを削除しようとしたら現在動いているコードに不具合が出たために削除ができない」といったケースを、見かける事があります。
これらは、特にエンジニアが増えたり交代したりした時に「莫大なコード読みコストがかかる」ために、主に費用面で、あまり馬鹿にできない側面があります。

こういった諸々の状況ですが。
もちろん「全体設計」なども関連してくるのですが、肝心の言語側の機能も、重要になってきます。
これがPHP4の頃ですと、色々と心もとない状況もあったのですが。
PHP5以降程度ですとクラスもある程度普通に使えますし、PHP5.3以降なら名前空間などで「名前がぶつからないようにする」事も容易です。
「エラーを例外で投げるか(或いはどのエラーを投げるか)」といった議論も比較的あちこちでありますが、PHPでも例外はサポートされましたし、PHP5.5以降であれば、finallyを使う事もできます(「RAIIに従って、デストラクタのほうが好ましい」という意見もあるかと思いますが)。
PHPでいわゆる「関数型プログラミング」をやっているケースはあまり拝見した事がないのですが、PHP5.3以降で無名関数がサポートされたので、やろうと思えばできない事もないか、と思います。
また、もし「コルーチン」のような機能が使いたい場合、PHP5.5でyield が実装されたので、そういった事も可能です。

こういった様々な機能は、色々と「必要に応じて」追加されています。
もちろん「知らなくても実装できる」のですが、知っていると「より効率的に、変更容易性の高いコードを書く事ができる」、かも、しれません。
そして、現在のPHPであれば、それらは「十分に記述が可能」な範疇にあると思うのです。

ですので。
もし「今からコードを書く」のであれば、変更容易性をしっかりと意識したコードを出来るだけはじめから書いていく、というのは、重要になります。
ただ一方で、特に運用経験等がない場合、「どうやったら変更容易性が高くなるのか」は、どうしても場当たりに学習していくケースも少なからずあるのではないか、と思います。

そのためには。
一つは「ある程度定期的にリファクタリングをする事」と、リファクタリングを定期的にやりやすくするために「テストを充実させる事」は、特に昨今、とても重要なお話になるのではないか、と思います。

次回から、リファクタリングとテスト回りについて、少し論考を重ねていければ、と思いますので、よろしくお願いいたします。