増11．技術的負債について
●今回の発端
保守や旧システムを見本にした類似機能を作るときには、どうしても現ソースの技術的負債について考えざるを得ません。
もちろん、あまりに負荷が高すぎて、否応なく負債を残すことはあると思いますが、どう見てもそれだけではありません。
その平時の負債発生のメカニズムについて、考えたいと思います。
●技術的負債とは
Wikipediaの「技術的負債」の項目には、例として、「組織で共有されない知識や、複雑すぎて変更が難しいコードなど」とあります。ここでは、プログラムの保守作業などの時点で、後の人が困ること一般を考えます。
●どこで起きるのか
テーブルなどではあまり起きないと思います。それは、
- 縦横か、せいぜいキューブ程度の構造なので、そもそも起きにくい。
- テーブルで技術的負債的なことが起きたら、関係者全員に耐え難い問題を引き起こす。だから負債を負債のままにしておけない。
- 必ず使うアクセスメソッド的なプログラムで補償が可能。
だからだと思います。
どこで起きるのかというと、間違いなく第一義的にプログラムでだと思います。マジックナンバーとはよくいわれますが、ここでの問題は「マジックロジック」といっていいと思います。
●何が起きるのか
保守や旧システムを見本にした類似機能を作っていて思うのは、プログラムにおける技術的負債は、プログラムの難読化と通じるものがあるのでは、ということです。
MS MSDNのVisual Studio 2008の資料で、バンドルされている難読化ツールについての文書には、
- 名前の変更（名前を、通常、1 文字に短縮）
- 文字列の暗号化（特定の文字列を検索して戦略的なロジックを探し出すことの回避）
- 制御フローの難読化（スパゲッティのように複雑にからみ合うロジック）
- 拡張オーバーロード誘導（メソッド名およびフィールド名の重複性を高める）
とあります。1つめの「名前の変更」は最近ではさすがに悪い例として回避されていることはあるとしても、間違いなく、筆者が「技術的負債」で「マジックロジック」だと感じている点と合致します（注：もちろんこれは「技術的負債」の一例であり、これ以外にもいろいろあると思います）。
●なぜ起きるのか
これについては筆者は目算があります。
- 「文字列の暗号化」はマジックナンバーを回避しようとして、定数一覧をただ1カ所に決めて定義したのはいいけれど、大量の定数ができてしまい、その定数の変数名の命名方法が実情に追いつけなくなる。大量なのでリネームも無理な場合、それはかえってマジックナンバーに近くなってしまう
- 制御フローの難読化と拡張オーバーロード誘導を行うと、ソースを修正・追記する際に、Diffツールで判別しやすいように修正することを奨励され、その結果、プログラムがバランスの悪い入れ子になってしまう
ためです。
この内、2つめの「文字列の暗号化」は、個々のプログラマではどうすることもできない問題ですが（“ただ1か所”という規約を無視して、サブ機能ローカルの定数一覧を作ってしまうことも、実際行われては居ますが、もし品質管理の監査が入った場合、ただでは済まなくなると思います）、制御フローの難読化と拡張オーバーロード誘導はプログラマで何とかしうる、実際に作譜しているプログラマにしかなんとかできない問題だと思います。
●なぜ起きるのを止められないのか
これは、実際に作譜しているプログラマが、プログラムは難しいと思い込んでいるからだと思います。難しいと思い込んでいたら、実際の譜面もそれに引きずられて難しくなるのは道理です。
プログラムなんて簡単もいいところなのですよ。筆者は、就職する前から一応（Tiny Pascalでありましたが）プログラムはできていましたので、逆に1週間もしない内に、「どう考えてもプログラム以外の要素（なにが正しいのかとか全体のアーキテクチャとか何とか）があって、プログラムなんて全体から見ると微々たるものだ」と気付いたりもしました。社会に出てからプログラムを学ぶとそれに気付くチャンスが失われるのかも知れません（気付いたときには、もう職業上致命的な言説を吐いていて、来世に期待するしかなくなっているような……）。
●起きるのを止める手立てはないのか
これは、「他人の目」だと思います。自分はプログラマで、他人から仕様をもらいテスト担当者に引き渡す役割ですが、技術的負債が有るプログラムを渡すと、テスト担当者の態度が一変します。ぎちぎちの遵法闘争を始めるのです（これはプログラマの感想であり、特定の組織の効果・効能を表すものではありません）。
（特にブラックボックスをテストの基本としている所はそうですが）テスト担当者は、プログラムの内部について意見できません。できないのは確かですが、彼らも内々ではソースについてもしっかり理解しているはずです。
意見できないため、その代わりにねちねち言ってきて、プログラマに反省を促しているのだと思いますが、実際に作譜したプログラマとテスト担当者は直接接することはないのが普通なので、そんな反省が生まれるはずもありません。
しかしながら、ここは1つ、テスト担当者を「他人の目」として認知した上、彼らの態度に注意し、自主的に技術的負債を除いていく必要があります。
●自分一人で、起きるのを止める手立てはないのか
よっぽど簡単なプログラムならともかく、難しく煮詰まってくると、プログラマには個人個人に「信念」が芽生えてきます。そしてそれはその当時の自分にはまったく分かりません（空気のように、魚の水のように）。
SFで脳梁を切断して、脳の効率をアップさせるなんて話もありますが、その位でもしない限り、自分1人では止められないと思います。
まぁ、今回はこんな所です。
●コラムのコメント欄の方針
コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。
ですので、このコラムで、
- わたしは基本的にコメントに答えない
- コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。