古いプログラムからも学ぶことがある…と思う。

機会がありまして、宮大工・西岡常一さんの聞き書き、「木のいのち木のこころ」を読んでいます。

木のいのち木のこころ 天・地・人 （新潮文庫） [ 西岡常一 ]

宮大工として過去の建造物の解体修理をしていると、過去の職人の仕事が見えてくるそうです。
建築から1300年以上経ってもなお現存する、法隆寺の建築仕事の素晴らしさ。
一方、そこから時代が下った、室町や江戸時代に建てられた寺社を見ると、便利な道具が発明されたことや、華美な装飾やコストカット、早い完成が求められたことなどを背景に質が悪化している、ということが見えるそうです。

そんな文章を読んでいるうち、まったくもって1300年という歴史はありませんが、「古いプログラム」に思いを馳せてみるのもいいかなぁと思いました。
…ということで、「『10年くらい前のソースを読んでうわって思った』5年くらい前の私」の話です。

当時私が担当していたアプリケーションの一部に、「Java1.4以前に書かれたんだなぁ」というソースコードが残っていました。
現在のビルド環境、動作環境は最新のJDKが使われていますが、ソースの書き方が「ジェネリクスがなかった時代」の書き方なんですね。

特に当時衝撃だったのが、
・クラスやメソッド名に意味がない。abb101, abb102, みたいなメソッド名が並んでる
・メソッドでコレクションを引数として受け取る場合は、配列。ListやMapを引数に取らない
の二点でした。

当時は、「何この古臭い書き方…」「理解できない」「ク○コード」くらいにしか思っていませんでした。しかし、改めて思い返してみると、今でも通用する設計上重要なエッセンスが含まれてるんです。

クラス名やメソッド名が読めない、意味不明なものである、ということは、別でこれらの一覧を定義した仕様書があった*1ということです。
仕様書があろうがなかろうが、読める名前にしたほうがいいのは間違いありません。
しかし、きちんと初めにメソッドを定義してからコーディングに入るという考え方自体は、TDDなどにも見られるように今も重要な考え方だと思います。

一方、引数を配列で取る、というのは当時のJavaの言語仕様の範囲内でなるべく問題を起こさないためのテクニックだったようです。キャリアの長い先輩エンジニアから以前、教えていただきました。
Java5でジェネリクスが導入される以前のJavaでは、ListやMapなどのコレクションの要素の「型（クラス）」を明示的に宣言する方法がありませんでした。
そのため、コレクションへの要素の追加時と要素の取り出し時で異なるクラスを使ってもコンパイルエラーにはならず、実行時に例外が投げられたり、予測しない挙動をする、という危険がありました。
これを防ぐため、メソッド間でコレクションを引き渡す場合、型の定義が可能な配列にあえて変換して引き渡すことで実行時エラーを回避する、というテクニックがあったそうです。

今の時代に置き換えますと、さすがにJavaのメソッド呼び出しでこういう事は起きないと思うのですが、Web APIの呼び出しで見られるような話ですね。
最近（…とは言え数年前か）は、RESTでは型が定義しづらいからgRPCなどのRPCを使って、プログラム内で型定義をする　という話もあるようです。

プログラム言語やフレームワークはどんどん進歩していますが、保守性が高い、読みやすいコードの要素というのは昔から変わっていないと思います。
ときには「ふっっっるい」ソースコードを読んで、当時の人の考えに思いを馳せてみるのもおもしろいかもしれません。

*1:どこかには現存しているのかもしれませんが、私は在処を知りません