技術的負債をいかに減らすか
はじめに
技術的負債が大きくなってしまったコード(=保守しにくい品質が低いコード)をいかに改善するか?という話です.コードの保守性を定量評価したいとき、どういう指標を用いるのがいいんだろう??
— Kensho Fujisaki (@ni66ling) 2015年4月19日
コミット時にその指標が悪化してたらリモートリポジトリへのコミットを禁止にしたり、コミッター別にその指標に対する影響度をグラフ化して、技術的負債を改善したい
対処策として,リファクタリングやテスト充実化(★)すればいいじゃないか?という意見が出てくると思いますが,
これを漠然と実行に移すのは,意外と簡単なことではないのではないかなと思っています.
実行に移しにくい理由として,大きく以下を挙げます.
[理由1] ★は短期的に見ると製品価値を生む行為ではないため,関係者(経営者)に対して説得力しにくい
[理由2] 実施後のモチベーションが続きにくい
ここでは,世間的にこの問題に対してどのように対処しているのかを簡単にまとめ,
その上で,どのように対処すべきか考えをまとめたいと思います.
事例
mixi http://alpha.mixi.co.jp/entry/2012/11552/alpha.mixi.co.jp
①ソースコード静的解析による技術的負債の見える化(定量化)
②①の指標改善度により開発者を評価ドワンゴ doda.jp
①技術的負債を短期間返済するための部署立ち上げ
②GitHub/IntelliJなどの開発ツール導入GMOペパボ http://engineer.typemag.jp/article/pepabo-devengineer.typemag.jp
①技術的負債返済のための部署を社長直轄チームとして立ち上げ
②CI導入
③技術的負債返済に関して開発者を評価
各事例における対処策の分類
1.~3.の対処策をまとめると,以下の5点に分類できると思います.
- 技術的負債返済のための部署立ち上げ
- ソースコード静的解析による技術的負債の見える化
- CIによる技術的負債の継続的改善
- 技術的負債返済に連動した開発者評価
- GitHub/IntelliJなどの開発ツール導入
どのように対処するか
はじめの「実行に移しにくい理由」に対して対処できるのではないかなと思います.
[理由1] → 2.による現状把握と,この指標によるデメリットの説明
[理由2] → 3.,4.によるモチベーション維持
対処策を具体化すると,次のようになるかなと思います.
- 2.について
Rubocop*1による各種指標*2を取得
取得した指標について,Rubocop規定値および世間的な標準値をもとに現状を評価し,本問題の重要度を明文化 - 3.について
2.の指標をJenkinsで管理.具体的には,RSpecの自動テストと同様に,コミット時にRubocopで各種指標の取得を実施 - 4.について
3.で取得した値について,各種指標の改善度/改悪度をチーム全体およびコミッター別に計上
技術的負債返済の進捗状況を透明化
以上を実際に試してみて,技術的負債の返済をトライしたいと思います.
*2:Cyclomatic complexity, Assignment branch condition size metric, Perceived complexityなど.http://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/Metrics