2010年10月27日水曜日

絶対的な保守性という幻想

ソフトウェア開発をしているとよく耳にする言葉に「保守性」があります。

  • 保守性は大事だ
  • 保守性の高いコードが良いコードだ
  • プログラマーは保守性に最大の優先度を置くべきだ
  • ○○本のやり方に沿えば保守性の高いコードが書ける
  • エレガントでインテリジェントなコードこそが保守性が高い

という主張も良く見かけます。

保守性が大事、という言葉そのものには大いに賛成です。

ただ、その「保守性」って一体なんなのよ?というところが曖昧すぎて
悪い意味で「こうすべき」という論調だけが氾濫しているのが最近すごく気になっています。

例えば「 A を10回画面出力しなさい」というお題に対して、次の二つのコードがあるとします。
コード1
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
echo "A";
コード2
$LoopCount = 10;

for( $i = 0; $i < $LoopCount; $i++ ) {
    echo "A";
}

さて、どちらが「保守性の高いコード」でしょうか。
おそらくほとんどの方は、コード2の方が保守性が高い、とおっしゃると思います。
というより、コード1はプログラミングの勉強初期に「こういうのはダメ」と教わる書き方です。

確かに、以下のような場面では、コード2の方が「保守性の高いコード」になります。

  • 「出力の回数を20回にしなさい」
  • 「コードの行数を出来るだけ減らしなさい」
  • 「A ではなく B を出力するようにしなさい」

ところが、以下のような場面ではどうでしょうか。

  • 「2回目だけ B を出力するようにしなさい」

この場合、コード1のほうが圧倒的に修正が早くなります。
また、こういった要求は往々にして次のようにエスカレートします。

  • 「さらに4回目だけ C を、5回目だけ D を出力するようにしなさい」

こうなるとコード2は完全に書き直しです。
一方、コード1は4番目と5番目の出力文字列を変えるだけで済みます。

これは極端な例ですが、このように一見稚拙で「ダメなコード」と
呼ばれているもののほうが「保守性が高い」という事が起こりえます。

ここで話のポイントは「コード2はダメ」ではなく「コード1の方が良い場合もある」です。

つまり、ビジネスの展開によって保守の内容はコロコロ変わるし
保守の内容によって保守性の定義もいくらでも変わります。

逆に言えば、未来にどんな保守が待ち受けているかわからない以上
保守性を正確に定義する事は不可能なわけです。

もちろんテクニカルなコードを書く事は素晴らしいことです。

でも、あまり石頭になってそこにばかりこだわると手段が目的になってしまい
窮屈で融通の利かない人になってしまいますよ、というお話でした。