正しさの向こう側

Webサービスを作って公開する度にいつも後悔するのが、「もっと奇麗にソースコードを書いておけばよかった」ということです。
完成後しばらくたってからコードを見返した際に、中身がぐちゃぐちゃで理解できなくなってしまっている箇所が多く、機能追加しようにも、どこをいじればどうなるのかという因果関係が全く掴めずに苦労してしまうのです。
RetroTubeを公開した時は、「ソースコードを見たい」と言って下さる方が多かったのですが、これは、知識のある方に見ていただけた場合、私にとって非常にプラスになります。
ところが逆に、プログラミング初心者の方が、私の書いたコードを「正しいサンプル」だと勘違いして捉えてしまうと、これは困ったことになります。
実際にWeb上で動作しているものとセットで公開しているので、コードが誤っているということはないと思うのですが、では本当にそれが「正しい」のかと尋ねられると、決してそうではないような気がします。
事前に策定した仕様通り動作するという意味では「正しい」のですが、どうもそういったレベルの「正しさ」よりも、さらに上位の「何か」があるのではないかと最近よく思います。

よく、「美しいソースコード」とか言ったりしますが、そもそもここでいう「美しさ」とは具体的に何のことを指しているのでしょうか。
その答えの一つは、有名な「DRY原則」のことなのではないかと思っています。
汚いコードの特徴の一つとして、同じ内容のロジックが複数箇所で別々に記述されていることが挙げられるでしょう。
これは、その場の一時しのぎでコピペしてしまったりすることが原因で起こるのですが、これをやりだすと素早くゴールには到達できるのですが、到達した後に残された「汚れたコード」と後々格闘していく羽目に陥ってしまいます。
プログラムが仕様通りにきちんと動くことと、将来に渡って楽々とメンテナンスできることは、全く別のことなのです。
つまり、「プログラムがきちんと動作する」という「正しさ」の向こう側に、「誰がみても理解でき、変更に強い」という「美しさ」や「強さ」があると言えるでしょう。

では具体的にどうすれば、DRY原則に従った美しいソースコードを書くことができるのでしょうか。
それは、「将来的に変更が発生する部分」を「変更が発生しない部分」から切り離し、なおかつ「変更が発生する部分」を一カ所に集約することであると私は考えています。

RetroHatebのソースコードでいうと、「将来的に変更が発生する部分」が、config.phpのことですね。
検索対象のサイトは今後も順次追加していく予定にしていますし、年代も月日が経つにつれて追加して行く必要があるでしょう。
これらの情報は、今後変更が発生するポイントであることがあらかじめわかっているので、config.phpに集約し、ここを変更することでアプリ全体の挙動を変えることができるようになっています。
こういった情報を、ソースコード内の複数箇所でハードコーディングしていると、いざ修正する際に、影響を調査するのが大変ですよね。さらに今後メンテしていく内に、このような箇所が知らず知らずの内にソースコード全体に渡って増殖していくことも充分起こり得るでしょう。

逆に、「将来的に変更が発生しない部分」については、フレームワーク部分にまとめられていると考えることができます。
「クライアントから渡ってきたパラメータに対応するMVCクラスを作成することでアプリが完成する」といったルールは、将来的に変更が発生することはまず考えられませんよね。こういった根本的な設計思想に紐づく要素については、ソースコード全体にうまくまぶしていくような感じになっているのが理想的です。

DRY原則を意識しながらプログラミングするのは、一見簡単なことのように見えて、実は非常にやっかいで労力を伴うものです。
けれどもその反面、難解なパズルを解いている時のような深い味わいがあるのも事実ですし、なにより出来上がったソースコードに対して今までより遥かに愛情がわいてくるようになりました。
ですので、今後も「正しさ」の向こう側にあるものを、それが一体何なのかも含めて、追求していきたいと思います。