Cで開発していた頃、ある程度の規模のプログラムに発展すると構造体に関数ポインタを配置してOOP的なアプローチになったりしていた。デバッグとかメンテナンス性は悪くなる。その後C++を使うのが一般的になり、メンテナンス性はまだしもC++に対応したデバッガでのデバッグは容易になった。
メンテナンス性を下げる最大要因は同じ名前のメソッドがひたすらあちこちにあること。ポリモーフィズムの暗黒面がメンテナンス性を下げる。標準的すぎるメソッド名に重要なロジックを隠しちゃダメってことだ。名が体を現してるうちはまだいいが、そんなものはすぐ破綻して、なんでこんな名前のメソッドでこんなことをってなる。
名前があればまだ良い方で、C++にはオペレータという必殺技がある。もちろん殺されるのはメンテナ。記号に独自の意味を付加するのは勘弁して下さい、マジ迷惑。Scalaは謎記号の宝庫で、そこが微妙に好きになれない理由の一つ。Dispatchとかできたら使いたくない。
無駄に継承が深いのも考えもの。ロジックとして1ファイルに収まってて欲しいようなことまであちこち見ないといけない。書いた奴はメンテナンスのことなんて考えてない。
さて、ある程度の規模のプログラムがさらに発展するとデータのやり取りに柔軟性を持たせるため、特定処理向けインタプリタになってしまうことがある。もちろんデバッグとかメンテナンス性は死ぬほど悪くなる。普通、独自インタプリタの独自スクリプトにはドキュメントは無く、加えて文法エラーすら教えて貰えない。
独自インタプリタって、作るのはきっと楽しいんだろうなぁ。でも俺にメンテナンスさせないで下さい。
2015.06.09
OSTRACISM CO.
OSTRA / Takeshi Yoneki