ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2010-12-10

[]技術的負債

Technical debt

最初のコードを出荷することは、借金をしに行くことと同じである。


小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。

ウォード・カニンガムさん

どういうこと?

技術的負債とは、コードにおける「修正しにくい」「理解しにくい」といった、問題のある部分のことです*1

一般的に、負債は、すぐに返済すれば、大きな問題にはなりません。しかし、長期間そのままにしておくと、利息が雪だるま式に膨らみ、もはや返済が不能なまでになってしまいます。技術的負債も同様です。問題のあるコードも、直ちに修正していけば大きな問題にはなりません。しかし、放っておくと、最終的に「機能追加」も「保守」もできないアンタッチャブルなコードと化してしまいます。

技術的負債は悪循環を生みます。

コードが理解しにくいと、機能追加に時間がかかります。また、バグの発見にも時間がかかりますし、バグの修正そのものにも時間がかかります。時間がかかるということは、影でまだ返済の終わっていない負債が膨らむということです。さらに、時間がかかるということは、その組織が本来するはずであった、もっと価値のある仕事をする時間を失った、ということにもなります。

問題のないコードはありません。問題を作りこんでしまった都度、それを早目に発見して、早目に手を打つしかありません。

どこから?

技術的負債の原因・増加には以下の要素が考えられます。

  1. 経験不足の開発者
  2. 締切りのプレッシャー
  3. 読みにくいコード
  4. 特殊化されたコード
  5. 不要に複雑なコード
  6. 単に悪い設計

技術的負債の原因には、開発組織の行動規範も考えられます。

  1. 「クリーンコード*2」を書こうとせずに、不明瞭なコードがあっても受け入れてしまう。
  2. リファクタリングに時間を割かない。
  3. システムを展開する直前になって回帰テストを実行する。
  4. 膨大な依存性を抱えた古いシステムのリプレースを躊躇する。
  5. 安易にコードをブランチさせる。

どうすれば?

管理者としての視点からは、以下の施策が考えられます。

  1. 開発者に、言語の基礎やオブジェクト指向の原理を教え、最低限の技術を理解させる。
  2. 開発者とマネージャーに、技術的負債にビジネスコストがかかっていることを認識させる。
  3. 開発者に、コードの臭い、リファクタリング、ユニットテスト、テスト駆動開発のトレーニングを行う。
  4. 開発者に、業務中の時間を学習時間としてあげて、スキルを磨けるようにする。
  5. チームに、ツールを与え、技術的負債の負担を発見し、減らし、測るのを助ける。
  6. 開発者に、獲得したスキルを報奨する。
  7. チームに、定期的に技術的なことを扱う学習セッションを作る。
  8. チームに、技術的負債のバッグログをメンテさせる。

開発組織や開発手法の観点から、以下の施策が考えられます。

  1. 特に経験の浅い開発者に「クリーンなコード」の書き方を訓練する。
  2. リファクタリングによって負債を解消する。
  3. コードベースが小さいうちに自動テストハーネスを使用し始め、コードベースへの追加と保守を行う。
  4. 依存性のなるべく小さいアーキテクチャを開発し、それに移行する。
  5. コードのブランチは、すばやくマージする。

感想

リファクタリング前のコードが技術的負債です。テストを作成し、テストが通ったら即座にリファクタリングして、負債を「直ちに」返済します。

既存のコードの保守には「ボーイスカウトの規則」の心構えを以ってあたります。

参考

*1:技術的負債は「バグそのもの」のことを指しているわけではありません。バグの温床、バグの発見の妨げとなる、問題のあるコードを指しています。

*2:誰が引き継いでも意図が明確に伝わるコード。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証