ソフトウェア開発と技術的負債

メンバーの技術レベルや、使えるリソース、世の中の技術の進歩などで、技術的負債（負い目）が出てくるというのは、よく言われるようになりました。大雑把には借金のようなものだと、個人的にはとらえています。保守・運用のフェーズで、ソースコードに手を加える際に、その借金を減らすどころから、更に増やしていないかを、もっと注意深くなるべきなのでは。

複利でふくれあがるのでトイチの借金はヤバいくらいに、もっと敏感になれないのだろうか。

例えばこんなコード

新しく特殊なケースのときだけにする処理を、既存の処理にフラグを足して追加する、というのはあるでしょう。次みたいにひとつくらいなら許容できそうですし、手っ取り早くて、簡単なお仕事な気がしてきます。

// もとのメソッド
public void hoge() {
 ....
}

// 追加処理をするかどうかのフラグを引数に追加
public void hoge(boolean flag) {
 ...
if (flag) {
  // 追加の処理
}

...

}

こんなことを2度、3度続けると、つぎのようにネストが深くなって可読性が落ちてバグりやすくなっていきそうです。

public void hoge(boolean flag1, boolean flag2, boolean flag3) {

if (flag) {
  // 最初の追加処理

  if (flag3) {
      if (flag2) { 
         // 2回目の改修で検討漏れがあってその対応
      }
  } else {
     // 3回目の追加処理
　　　
  }

} else {
    if (!flag2) {
       // 2回目の追加処理
    }
 }

}

わざとひどく書いてますが、気が狂いそうですね･･･
オーバーロードで、使うケースを限定させるようなメソッドも追加してあればまだよいですが、そのまんまを色んなところで呼び出していたら、このメソッドがなにをするのか段々わからくなってきそうです。

hoge(true, false, false);

hoge(false, true, false);

hoge(false. true, true);

実装の手間をはぶくのによくやること

手軽に（何の工夫もなく）実装できてしまうということは、技術的な借金をしている可能性が高いです。次のようなことをやると、短期的には手間が省けることは多いでしょう。

• ハードコーディング
• マジックナンバー
• 手続き的な処理
• 既存のメソッドに引数追加や処理の追加
• パッケージを切らずに、新しいクラスを追加
• 新しいクラスをつくらず、既存のクラスに追加
• StringのMapを多用

要は、オブジェクト指向的な設計をしない、そのための言語機能を使わない、ということです。
こんな継ぎ接ぎを続けていくと、どんどんコードもドキュメントも変更しにくくなり、可読性も落ちていくでしょう。

これをやったら、きっとトイチやトサンで借金するようなものです。