技術負債の解消〜みたいな話がチームで出た時に、話のスタートラインに〜ってので何度か投下したのでとっかかりの議論をまとめました。

そもそも技術負債とは

生みの親のWard Cunninghamがその背景を説明してくれている動画を id:t-wada さんが紹介してくれていて、その内容はよく言われているものとは結構違います。

t-wada.hatenablog.jp

こちらのブログのt-wadaさんによる解説を引用します。(レイアウトの都合で改行足してます)

Ward の言う負債の悪影響とは、開発と共に得られていく知識や理解と
目の前のシステムとの乖離が引き起こす生産性低下のことであり、
自分たちが書いているコードの保守性（あるいは、雑さ）のことではありません。
むしろコードを書くときには常にそのときのベストを尽くせと言っています。

Ward にとって負債の返済手段はリファクタリングであり、
リファクタリングの目的は自分たちのドメイン理解と現時点のプログラムの乖離の解消です。
つまりこのリファクタリングとはドメイン駆動設計（DDD）における
「より深い洞察へ向かうリファクタリング（Refactoring toward deeper insight）」
のようなものと言えるかもしれません。

これを読んだ上で自分的なポイントは、一口に技術負債と言っても、それによるイメージは多義的になってしまっているということです。なので自分が「負債解消」って言った時に、どういう意味合いで言ってるのかは自分の中できちんと理解しておき、場合によっては別な言い回しができるようになっておきたいところです（対象の理解）。以降の部分では、基本的に「自分たちが書いているコードの保守性（あるいは、雑さ）」と言ったイメージで負債解消を使います。

技術負債の解消どうする？

さて、対象が理解できたとして、次にその負債は解消すべきなのかどうかを考えます。代表的な負債解消の方法はリファクタリングかなと思うのですが、ここで自分が意識しているのは、Mertin Fowlerの「リファクタリングはEconomicsで正当化せよ」というものです。こちらのトーク動画（Agile Singaporeのクロージングキーノート）から見られます。

youtu.be

雑にまとめると、リファクタリングをプログラマの嗜みや、正しい行いとして正当化してはいけない、リファクタリングはEconomicsで正当化せよ。というものです。

このトークは直接聞いていたのですが、衝撃を受けたのを覚えていて、以来意識するようにしています。

実践

正当化しなければならない（くらい大掛かりになってしまった）ケース

「リファクタリングをバックログに積みたくなった時点でもう負けが込んでる」って昔TDDBCでコメントもらった気がするのですがその通りで、もはやこれは厳しい、って場合はEconomicsで考えます。そしておそらくそのEconomicsは、少なくとも今起きている実害についてはある程度可視化できると思われるので、可能な限り可視化・数値化を頑張ります。その上でストーリー立てして、Economicsのまな板の上で議論して堂々とやりましょう。

例えば自分がやった取り組みとしては下記があります。

小規模なもの

先のt-wadaさんのブログにもあった通り、「むしろコードを書くときには常にそのときのベストを尽くせ」です。

同じ考え方はいろんなところで語られていて、例えばアジャイルサムライでは、「積極果敢なリファクタリング」って紹介されています。

積極果敢なリファクタリングとは、イテレーションの終わりにまとめてリファクタリングすることじゃない。
一日を通じてたゆまず、継続的にリファクタリングするってことなんだ。
物事がうまく運んでいれば、リファクタリングはほとんど目につかない。
手順は少ないし、改善内容も細かい。
だから作業工程としてリファクタリングなのか、新機能の追加なのかを明確に区別することはできない。

Mertin Fowlerも、「リファクタリングはTDDのコンテキストで教えられる」と言っています。日々の活動の中でTDDが入っていれば、リファクタリングは日々の活動に溶け込んでいる基本のキと言った扱いになります。

martinfowler.com

この場合は、そもそも小さすぎて説明不能だし、ただ全力を尽くしているだけです。説明せずに果敢にやりましょう。ただし時間のかけすぎや過設計には注意、負債になります。