futoase

よろしくお願いします。

技術的負債 (Technical Debt)

最近色々と出てくるが、これって以前から言われてる単語だよな。 ということで調べてみると、技術的負債とは?対処法とは?の内容が詰まった記事が見つかった。

www.infoq.com

記事に取り上げられている内容は多岐に渡り、またある程度のシーンに当てはまると思う。 その中で印象的な一文はこれだった。

クリーンアップリリース

時々コードベースを改良するために、純粋な技術的リリースをするチームがあります。このアプローチは、本当に必要なリファクタリングのリストがすでにある場合にのみ役に立ちます。それ以外は、チームは重要ではないリファクタリングのために時間を無駄にするリスクを負います。このアプローチは新しい機能が遅れるかもしれないので、ビジネス側のサポートを得られなければなりません。それには、もちろん、ビジネスの人たちが技術的負債を理解している必要があります。大きな労力が必要になるならば、コードベースをクリーンにして、アーキテクチャを再構築するために、純粋な技術的リリースを考えるべきです。例えば、コードの同じ部分が、開発中や運用中にいつも問題を引き起こすかもしれません。今のアーキテクチャは、今の要求にもう合っていないのかもしれません。そのような問題は小さなリファクタリングでは解決できません。クリーンアップリリースは大きな変更を可能にします。

沢山の技術的負債を作り出した、非常に慌ただしく、緊急を要するリリースの後で、クリーンアップリリースをすることは考えにくいことです。新しいコードベースにわずかな経験しかなく、コードのどの部分を改善する必要があるのか誰も言うことができせん。それほど改善の必要がないコードを変更するのは危険です。

たぶん、Google検索で技術的負債と検索して引っかかるブログエントリー、 Qiita記事で取り上げられている技術的負債への不満点はこのクリーンアップリリースへの 思いで作られているんじゃないだろうか。

  • ビジネス的に、日程が決まっていて結果主導で書いたもの
  • 目的もわからず手探りで書いたコード
  • 学習しながら作った成果物
  • 設計書のない、一次情報が欠けている成果物

あとでなんだっけ?となったときのメモ書き。

Copyright (c) 2013-2017 Keiji Matsuzaki