ソースコードは自分を映す鏡なの？
こんにちは。草食系妙齢プログラマ 野口おおすけです。先日の勉強会カンファレンス2010で、エンジニアライフ コラムニストの森姫さんとkwappaさんとご一緒しました。kwappaさんとは、ほかのイベントでご一緒することが多いのですが、森姫さんとは共通の知人がいるものの初対面でした。いろいろな方に直接お会いできるのもイベントに参加する醍醐味の1つですね。
今回は、前回に引き続いて「ミステリアスソース」についてお送りします。前回は、ミステリアスソースの問題点、なぜ発生するかという話題をお送りしました。今回は、ケーススタディをとおしてミステリアスソースを見てみましょう。
■あれ？ これどこかで見たソースなんだけど……
どの言語でも、同じような処理を複数の場所で行う場合にはファンクションを作成し、それを呼び出すことで処理の共通化を行います。Javaの場合、修飾子をつけてそのメソッドのスコープ（公開範囲）を決めて、不必要なメソッド呼び出しを行わないようにします。同じソースの中で同じ処理を複数回書くのを避けることで、バグの原因を狭い範囲にとどめられます。
これを無視して、同じ処理をコピーして複数回ソースコード内に記述してしまうと、どうなるでしょう。ソースの複雑度が一気に上がります。問題が発生した場合、コピーした部分すべてを確認しなければなりません。また、テストも同様にすべての修正箇所に対して行わなければなりません。
作成時は、Ctrl＋CとCtrl＋Vを繰り返すだけで、ソースコードは完成します。しかし、修正にかかるコストは正しくファンクションを利用したうえで構築したものに比べると、数倍以上に膨れあがります。同時に、同じだけの品質を担保するためのテストの工数も一気に上がります。
このようなソースが発生する原因は、多くの場合は設計段階で共通処理の洗い出しが正しく行われていないからです。コピー＆ペーストが行われるということは、同じ処理があるということです。その内容について、設計書から読み取れればいいのですが、そのすべてを記述することは難しいでしょう。ソースコードを作成する側でコピー＆ペーストを行う前に、処理の共通化を行えるかどうかを考えてから実装する必要があります。
「ステップ数が多い＝いいコード」というわけではありません。また、ステップ数でプログラマの価値が決まるという古きよき日本のプログラマ文化は、もう存在しないといっても過言ではないでしょう。
■え？ これがベストの実装？
例えば、日付の妥当性確認の実装について考えてみましょう。1月32日など存在し得ない日付を指定した場合はチェックNGとするようなロジックです。どのようなアプリケーションにもあるような基本的なロジックです。このロジックの実装には様々な手法があります。使用している言語が持つ標準APIを利用する方法や正規表現でチェックする方法などがあります。
Javaの場合、日付を扱うクラスを利用して妥当性を確認できます。しかし、これを利用せずに1月は31日までしかなくて、2月はうるう年があるから月末日が変わって……13月はなくて……ということをすべて実装すると、ロジックは一気に膨れ上がります。それをテストするとなると……あぁもう考えたくない……となりませんか？ わたしはもう、2月の時点で心が折れてしまいそうです。
さすがに、実装法を細部にわたって記述している仕様書はありません。もし、あったとすればプログラムの数倍の物量になり、プロジェクト全体となれば電話帳くらいの量になってしまうでしょう。管理するのはもちろん、持ち運ぶのも大変です。実装法の選択はプログラマに任されています。
プログラマは常に、最適な実装を目指す必要があります。わたし自身、それが常にできているか？ というと、そうではありません。ペアプログラミングやソースコードレビューなど、別の視点からソースコードを見直すことで補っています。ときには、ソースコードレビューで厳しいことを言われることもあるでしょう。しかし、自分の考えとレビュアーの考えとのコミットメントを取ることは重要です。他人に説明できないソースコードには、何かしら問題が潜んでいます。またレビュアーも、その意思を聞き出すことに重きを置くべきです。「コメントが～～」とか「インデントが～～」とか「ステップ数が～～」とかつまんないことを言っても仕方ないのですから。
2回にわたって、ミステリアスソースについて紹介してきました。自分の書いたソースがいろいろな人の目に触れるということは、かなりのプレッシャーです。例えば、ブログに書いたソースコードが見られて「え～あの実装イケてないよ～」と言われることもあります。
でも、大抵の場合、そういうことって忘れてしまうものです。次の機会にそれを直しておけばいいだけの話なんです。社内社外問わず、いろいろな人の目に触れることを恐れず、ソースコードをさらす勇気を持ちましょう。きっと、自分で作成するソースに自信を持つキッカケを作れると思います。
自信をもって書かれたソースは、ミステリアスソースにはなりにくいものです。哲学的ではありますが、「ソースコードは自分を映す鏡」なのです。自分が不安に思ったところには必ず、バグやミステリアスソースになる要素が含まれています。1人ひとりが作るソースコードの健康が、アプリケーションの健康やプロジェクトの健康に繋がります。
次回は「エキセントリックマネジメント」ということで、不思議なチームマネジメントについてお送りいたします。関東は梅雨入りしましたが、夏のような暑い日が続きます。ビールがおいしい季節ですが、くれぐれも飲み過ぎないように過ごしましょう。それでは、また次回。