それは神秘的なソースなの？
こんにちは。草食系妙齢プログラマ 野口おおすけです。iPadに引き続きiPhone 4の発売が決まって、予約受け付けが始まりました。わたしはAndroid携帯ユーザーなのでしばらく様子見ですが、周りでは予約したという話を聞きます。ちょっとうらやましい今日このごろです。
さて今回と次回の2回にわたって、「ミステリアスソース」についてお送りします。最近ではレガシーコード（テストコードを持たないコード）にいかに対処するかということや、TDD（テスト駆動開発）などプログラムを読みやすく質の良い状態にするためのさまざまな取り組みが検討されています。しかし、残念ながら、読みにくいソースコードは数多く存在します。これから、そのようなコードに対する対処法などを考えていきます。
■ミステリアスソースって？
日々の業務の中で、さまざまな機能の実装を行います。実装を行う際は、利用している言語の特性を考慮し、無駄なロジックを組み込まないように注意しながら、作業を進めます。作成しているものが仕様と差異がないか、処理速度に問題は出ないか……こういったことを考えながら実装を行います。開発の中で一番楽しくもあり、一番苦しくもある時間です。
しかし、しばらく時間が経ったあとにソースコードを読んで、「なぜこのような実装になっているのか」と疑問に思ったことはないでしょうか。経験上、自分で作成したものならまだ読めますが、他人の作成したものとなると一苦労、ということが良くあります。新しい技術を習得して「こんな実装しちゃって恥ずかしいなぁ。書き直したいなぁ」という振り返りのキッカケになることはよいのですが、トラブル発生時にソースを読み返して「何じゃこりゃ……さっぱり分からんぞ……」となるようなソースでは問題です。
「ミステリアスソース」は、単にスパゲッティコード（構造が極度に複雑化してスパゲッティのように絡まっている状態のソースコード）を指すわけではありません。「ミステリアスソース」は、「実装者の意図が分からないソースコード」なのです。
■ミステリアスソースはどこにある？
それでは、ミステリアスソースはどこに隠れているのでしょうか。少し分析してみましょう。
1.そもそも動作していないソース
これがプロダクトソースに含まれていると問題です。「そのようなソースはない」という前提に立っても問題ないでしょう。万が一、プロダクト全体に無駄なソースコードが大量に含まれていると、検出することも難しくなります。まず、使われているかそうでないかの切り分けから始まりますので、検出するのにも時間がかかります。
2.動いているが、仕様と異なる挙動をするソース
一般的にバグと言われるものです。これは、バグと思われる動作を再現させて、挙動を確かめて該当するソースを絞り込むという作業になります。問題部分を修正して問題となったオペレーションと同じことを行って動作を検証します。同時にデグレッションテスト（退行テスト）も行います。このとき、JUnitやRSpecなどのテストコードがあると、作業も楽になります。
3.動いているけれども非機能要件を満たさないソース
「処理時間は○○秒以内であること」のように、機能ではありませんが満たさなければならない要件を「非機能要件」と呼びます。これらを満たしていないソースは、リリース後に問題となりプロファイラでチェックしたり、オプティマイザとにらめっこして、問題を分析しパフォーマンスチューニングを行います。ソースコードを直接修正するだけでなく、データベースのチューニングなどミドルウェアの設定を修正することもあります。
それでは、ミステリアスソースはどれに含まれるのでしょうか。多くの場合１～３のどれにも含まれません。ミステリアスソースの多くは、正常に動いているソースに含まれるのです。だったら、修正しなくてもいいんじゃない？ と考えられることもできます。
破れ窓理論（一部のソースの荒廃を許すと全体に派生する）に従うのであれば、一部のミステリアスソースは、全体に影響を与えます。全体がミステリアスソースになってしまったプロジェクトでは、一度問題が発生すると、通常のプロジェクトにくらべ修正にともなう時間も手間もかかります。また、作業者のモチベーションを極端に下げます。見つけ次第、すぐに修正したいものです。
現実として、正常に動いているソースコードに手を加えることを避ける場合が多く、事態が改善されることなく放置されているといったことが多くあります。ミステリアスソースを改善するよりも、発生しないように取り組みを行う必要があります。
次回は、ケーススタディを通して、ミステリアスソースの発生や問題点について、もう少し深く考えてみましょう。それではまた次回。