ここまでの何回かの投稿で、Swift言語やiOS APIの仕様確認の話を書きました。良い機会なので、仕様確認に関する話を少し突っ込んで書いてみます。
まず、仕様確認という用語から。残念ながら、仕様確認という呼び方は、一般的ではないと思います。おそらく、私が勝手に使っているだけではないでしょうか。つまり、私の個人的な呼び名です。
わざわざ特別な名前をつけて呼んでいる理由ですが、何か名前をつけないと説明しづらいので、とりあえず付けたという感じです。勝手に付けた名前ではありますが、意味は上手に伝わると思っています。
肝心の「仕様確認」の意味を説明しなくてはダメですね。公開されている言語仕様やAPI資料には、細かな部分までは記載されていません。その細かな部分が「実際にはどう動くのか」を、具体的なコードを書いて動かし、調べる行為のことです。より正確に表現するなら「詳細仕様確認」という感じでしょうか。
もちろん、何から何まで調べるわけではありません。自分が気になった箇所、または疑問を感じた箇所だけ、絞り込んで確認するだけです。
言語やAPIの資料で、細かな部分まで記載されていないのには理由があります。おそらく一番大きい理由は、作業量が膨大になることでしょう。
例として、is演算子の場合を考えてみましょう。仕様を簡単に書くとしたら、次のようになるでしょうか。データ型を調べるための演算子で、調べる対象となるものを演算子の左側に置いて、データ型を右側に入れます。左側のデータ型が、右側のデータ型と一致すればtrueを、一致しなければfalseを返します。以上のように、非常に簡単に書けて、それなりに意味は伝わります。
しかし、これでは厳密な仕様とは言えません。まず、左側に入れられるものの範囲、同じく右側に入れられる範囲が不明確です。また、データ型が一致するとは、どの範囲まで含まれるかも不明確です。また、左右の組み合わせによって、一致する範囲の説明が異なることも考えられます。これらを明確に規定しないと、厳密な仕様にはなりません。ここまでの説明を読んだだけで、きっちりと説明するのが如何に大変なのか想像できると思います。is演算子だけでこうですから、全部の機能を同じように説明したら、物凄い量の文章量となり、その作業量も膨大になると推測できるでしょう。
もう１つの理由としては、正確に書ける人が非常に少ない点も挙げられます。細かな部分まで正しく理解できるだけでなく、分かりやすく正確に書ける文章力も必要です。おそらく、普通の人には難しいでしょう。
他にも理由はあるでしょうが、結果として、現状のような「簡単な説明だけ」で落ち着いているわけなのです。おそらく「細かな動きは、動かして調べられるから、自分で調べてよ」という考え方なのでしょう。現状の形が「現実的な落としどころ」だと私も思います。
現状の資料が細かな仕様まで含まれていない以上、本格的に使う場合は、実際の動作結果を自分で調べるしかありません。「こう動くだろう」と考えてソースコードを書きますが、本当に「こう動く」かどうかは、試してみないと何とも言えません。
今までの経験上、多くの場合は期待した通りに動くものの、たまに期待どおりに動かないこともあると知っています。だからこそ、できるだけ事前に仕様確認して、正確な動きを知っておくようになったわけです。
実際には、何から何まで仕様確認しているわけではありません。大抵の場合は、次のような流れになります。まず最初に、作りたい機能をiOS実験専用アプリ上で作ります。その際に、作った機能をテストするわけですが、正常な動作のほかに、エラーになる動作も含めます。それら両方が期待どおりの結果なら、仕様確認する必要はありません。
ところがまれに、期待どおりの結果が得られないこともあります。当然ながら最初は、自分のプログラムのバグだと思います。でも、いくら直してもバグが消えず、どう考えてもバグがなさそうとだと感じたあたりで、仕様確認を試そうと考え始めます。どの辺の機能が期待どおりに動いてなさそうなのか、バグとして現れている実行結果から予想して、ターゲットとなる機能を絞り込みます。
絞り込めたら、仕様確認のコードを作ります。同じiOS実験専用アプリ内の別な場所(通常は隣の場所)に、仕様確認の機能を割り当てて、そこに作り込みます。作ったコードを実行すれば、API資料に書かれていない仕様を知ることになります。得られた実行結果によって、元のコードを変更するか、別な機能を使って実現するか、今後の方針を決めるわけです。
作りたい機能のコードも、仕様確認のコードも、同じiOS実験専用アプリ内に保存されます。たいていは隣に入れておきますから、APIのバージョンアップなどで細かな仕様が変更された場合でも、連続して実行できて便利です。
期待どおりの実行結果でなかった場合は、その結果を何かの形で残すことも大事です。実行結果は保存されませんから、対象となる仕様確認ソースコードの中に、コメントとして記録しておきます。XcodeやAPIのバージョン番号とともに。
以上の例とは違って、仕様確認を先に行なう場合もあります。
作りたい機能を実現するために、どのAPIが使えるか調べているとき、細かな仕様が不明とか、使い方が不明というケースが意外に多くあります。実際に動かしてみないと、本当に使えるかどうか分からない場合は、仕様確認のためにコードを用意して調べます。この場合も、iOS実験専用アプリを使って、その中に作ります。
仕様確認の結果、そのAPIが使えると判断したときは、作りたい機能を同じiOS実験専用アプリ内で作ります。前の例と同じように、仕様確認コードの隣に作って、近くに入っている状態にします。作る順序は逆ですが、作られた状態は似たような形となります。
さらには、作りたい機能とは関係なく、仕様確認を行なう場合もあります。
どのような機能でも、特別な条件のときに正しく動作するか、確認してみたくなるケースがあります。特定の機能を並列で複数動かしたときに正しく動くかとか、一般的ではない使い方での動作です。
このような疑問を生じた場合は、やはり仕様確認を行ないます。iOS実験専用アプリ内に確認用コードを追加し、実行させて確かめます。こちらの場合には、作りたい機能のコードはなく、仕様確認のコードだけが保存されます。
作りたい機能も仕様確認も、一緒のiOS実験専用アプリに入れるのには、もう１つの理由があります。
一番大きいのは、作る手順でしょう。新しい機能をアプリ内に追加する場合、非常に簡単な機能でない限り、アプリ内で作り始めることはありません。まずiOS実験専用アプリ内で作って、本当に作れるかどうか試します。その後、ライブラリ化できないか考えたり、より共通で使える形に直したりします。そのような過程を経てから、アプリ内にコードをコピーするのが通常の流れです。
結果として、作った機能が再利用しやすく整えられることはもちろん、テストするコードもiOS実験専用アプリに残ります。アプリへ持って行くのは、テストまで終わったコードだけです。
このような手順でアプリを作ると、アプリ内だけで作るコードは、アプリ独自の機能だけに限られます。また、テスト用のコードも、アプリ独自の機能だけに絞られます。
Swiftを使い始めた頃は、iOS実験専用アプリを持っていませんでした。そのため、最初に作ったアプリでは、アプリ独自の機能以外のコードも多く含まれています。
Swiftに少し慣れたころ、iOS実験専用アプリを思い付いて用意しました。それからは、新規の機能はiOS実験専用アプリで作り、作り終わったらアプリへ持って行く形にしています。また、過去に作ったアプリの機能のうち、独自ライブラリの形で作れそうなものは、少しずつライブラリ化を進めています。
最初の頃に作ったアプリも、バージョンアップの際に、新しい独自ライブラリに入れ替える予定です。
ここまで、仕様確認について色々と書きました。仕様確認の必要性だけでなく、確認用のコードを残すことや、iOS実験専用アプリとの関係まで含まれます。
最初に述べたように、言語やAPIの資料には細かな仕様が書いてありません。自分で実行して確かめ、細かな仕様を調べる必要があります。
細かな仕様を知ることは、APIで提供される機能を正しく理解することになり、気付かないバグを減らすことにも繋がります。アプリの信頼性を向上させるためにも、自分のスキルをアップさせるためにも、疑問に思った点は仕様確認してみてください。
