年末なんで大掃除(技術的負債のたな卸し)してみよう。

Last updated at 2017-12-25Posted at 2017-12-23

この記事は富士通クラウドテクノロジーズ Advent Calendar 2017 の23日目です。
昨日は@kzmakeさんの分離型のコンパクトなキーボードlet's split(レツプリ)を組み立てた話でした。
久しぶりにハンダゴテ出して工作したい気持ちになりますね！おっっっしゃれー

はじめに

今年も終わりますが大掃除はしましたか？
気持ちよく年を明けるためにも、今年の負債を整理して来年度のスタート切りたいですよね。
今年も終わりそうなので、今年中できていなかった負債の棚卸しするにために負債回収方法を調べました♪
年末にプロダクトの振り返りを考えている方は是非御覧ください!!

技術的負債の棚卸し

掃除するための準備は、まず整理から

技術的負債というと、とてもマイナスなイメージに聞こえますが、
開発を続ける中での理想状態との差分を揶揄する言葉です。
継続的に開発していると、多かれ少なかれ理想とギャップできますよねー。
負債ができる要因は、「使いなれていない流行りのライブラリを使った」
「完成させるため実装速度を優先した」「時が経ち、バージョンが古くなった」など様々です。

まずは、現状把握のためにも、負債を認識するところからはじめてはどうでしょうか？

step1. 負債を列挙する

コードや仕様書をみながら、思いつく限り負債を列挙し、
負債を大まかに負債の種類ごとに分類します。
よくありそうな負債の分類は、以下のような感じですかね。

コードの負債
- 〇〇は、もっとスマートな実装方法で書き換えられた
- 〇〇と☓☓間で循環参照がある
- 〇〇メソッド、〇〇クラスが仕事をしすぎている
- 正常系、異常系のテストパターンが不足していた
- 突貫工事により、パッチ処理を書いたまま放置したまま
- 各レイヤーの責務が整理されておらず、スパゲッティ
システム構成など設計の負債
- リクエストが集中してもオートスケールしない
- 〇〇が冗長構成になっていない
- バリデーションが誤っており、意図しないデータがDBに入ってしまった
技術環境の変化による負債
- 当時流行っていたライブラリより、イケているライブラリがでた
- メンテされていないフレームワーク、ライブラリを利用している
- 使用しているサードパーティなライブラリが使ってみたら、他のライブラリ等と相性が悪かった
- LTS対応のバージョンが上がった
- バージョンアップすべきライブラリがあった
- 推奨されるシンタックスが変わった
運用レベルの負債
- 引き継ぎ漏れ等により、ある処理・仕様の意図が分からない
- 資料の置き場が集約されておらず、どこにあるか分からない
- 一部仕様がわからず、バグ回収に多くの工数を費やした
- 手動メンテ手順が多く、オペミスが発生したことがある

step2. リスクを考える

負債を列挙し終わり課題感が見えてきたら、
リスク内容／度合いをつけると優先順位が可視化され、
対応検討しやすくなります。

イメージとしては以下のような感じです。

負債内容	リスク内容	リスク度合い
〇〇は、もっとスマートな実装方法で書き換えられた	冗長でコードが読みづらい	低
〇〇と☓☓間で循環参照がある	メモリリークを引き起こす可能性,requireしたモジュールのメソッドやプロパティがundefinedになり意図しない挙動を引き起こす	高
…	…	…

負債回収の棚卸しした項目は全部回収する必要があるとは限らないので、
「やりたいことに必要な時間 > 利用可能時間」の場合には開発メンバー・責任者と相談し、
許容できる水準を話し合い、どこまでやるか決めましょう。
また、負債のリスクを分類し、優先度合いを可視化しておくことで、
事前にリスクヘッジしやすいので少しはマシな説明ができるはず...(そう信じたい)

before:「〇〇の仕様変更があったため遅れました、てへぺろ」
「連携サービスの〇〇の変更により、本サービスでバグが流出しました、てへぺろ」
after: 「〇〇の仕様変更があると☓☓に影響あるかもしれないので、遅延リスクが発生します、キリッ」
「連携サービスの〇〇の変更は、重大リスクにあげた☓☓に影響あるので対応の可否を確認します、キリッ」

頑固な汚れ(計画的に掃除が必要なもの)への対処法

負債の棚卸しが完了し、優先順位がみえてきても、
簡単に回収できない負債もあるかもしれません。

例えば、「〇〇と☓☓間で循環参照がある」は設計段階から見直す必要があり、
大きなリファクタリングが必要になるかもしれません。
大きなリファクタを伴う、そんな頑固な汚れは計画的に対応しなければいけません。

step1. 大きなリファクタが必要か判断する

クラス図を作成し、各レイヤーの依存関係を確認します。
リファクタしたい対象と変更した場合の影響範囲を考察します。
また、大きなリファクタをするという判断が必要な場合はメンバーの合意が必要です。

大きなリファクタリングは、すべてのプログラミングチーム間で、
あるレベルの合意が必要になります。※1

step2. 大きなリファクタ時の戦術を知る

リファクタリング名	リファクタリング対象	対応策
継承の切り離し	1つの継承階層で２つの仕事をまとめて行っている	２つの継承階層を作成し、片階層は"機能"にもう片階層に"実装"に分離する＝Bridgeパターンの適用
手続き的な設計からオブジェクトへの変換	手続き的な形式で書かれたコード	手続き型で書かれている操作対象をオブジェクトに変更して、振舞いを分割してオブジェクトに移動する
プレゼンテーションとドメインの分離	問題領域のロジックを含んでいるView、Controller	問題領域のドメインを別のドメインに移す
階層の抽出	仕事をし過ぎているクラスがある。少なくとも多くの条件分岐を持つ部分がある	クラス階層を作成し、1つ１つのサブクラスが特殊条件を表現するようにする

上記は新装版リファクタリング―既存のコードを安全に改善するの第12章大きなリファクタを参照にまとめたものです。
それ以外にも大規模な変更を徐々に進めていくときに、BranchByAbstractionというテクニックは便利そうです。
(残念ながら、使用したことが無い...)

BranchByAbstractionを軽く説明すると以下のような流れです。

抽象化レイヤーを作って、クライアントのコードとモジュールとのやりとりを抽象化レイヤーに閉じ込める。

クライアントのコードの中で該当モジュールを呼び出すのではなく、抽象化レイヤーを経由するように変更

新しいモジュールを作成し、抽象化レイヤーを呼び出すようにする(問題のあるモジュールから新しいモジュールへ徐々に切り替える)