循環的複雑度の計測
背景
テストコードもない複雑なレガシーコードに対して変更する場合、常にデグレードのリスクが伴います。エンジニアの知見や経験によってそれを回避することも可能ですが、チームとして取り組む上では仕組みでそのリスクを軽減する必要があります。
以前、チームでレガシーコードに対して修正したとき、PR でレビューしたにも関わらず、デグレードが発生しました。原因を分析していくと、対象のメソッドは変更前から循環的複雑度が50を超えており、変更後はさらに数値が上がっていましたが、そのことをチームとして認識できていない状況でした。その他にも因子はありましたが、実装中からバグの混入確率を減らすことが期待できる仕組みの１つとして循環的複雑度に着目しました。
実際にバグ分析からプロセスを改善したときの方針と内容を以下に記載します。
方針
内部品質が低下することにより、バグの混入確率が上昇するため、内部品質を定量的に評価できる指標の１つとして循環的複雑度を用いる。 変更したコード、新しく追加したコードに対してバグの混入確率を循環的複雑度で評価し、定量的な指標をもとに適切に対処する仕組みを構築する。
循環的複雑度が低いことは内部品質が高いことの必要条件である。しかし、必要十分条件ではないことを留意する
期待する効果
循環的複雑度を把握することにより、現在より以下の効果(=バグの混入確率低下)を期待する
- レビュイー自身がレビュー前に循環的複雑度が高いコードであることを認識することにより、事前に循環的複雑度を下げるためのリファクタリングや単体テストとして網羅率が十分であるか確認できる
- レビュアーが循環的複雑度が高いコードであることを認識することにより、循環的複雑度を下げるための内部設計として改善の余地がないか、バグが混入していることを前提としたコードの確認ができる
改善するプロセス
今後、循環的複雑度を把握し、バグの混入確率を下げるための取り組みとして以下を実施する。
- Pull Request 時に修正前後のメソッド、新規のメソッドに対して循環的複雑度を計測する
- Merge する条件に循環的複雑度を追加する
- 修正前が30未満の場合、修正後が30以上の場合は NG とする (修正後が30未満であれば前回より増加しても需要する)
- 修正前が30以上の場合、修正後が前回を超える場合は理由を記載する
- x.x.x 以降は NG とする
- 新規が30以上の場合は NG とする
技術的負債の種類と対処
技術的負債の種類と対処
開発チームの会話の中で 技術的負債 というワードを口に出したり、聞いたりすることがよくあるかと思います。 その技術的負債がイコール悪というコンテキストで会話していることに違和感を持っていました。
ある日 More Effective Agile ~“ソフトウェアリーダー"になるための28の道標 を読んでいると、技術的負債にはさまざまな分類法があり、その中で著者が有益と考えている以下の分類法が紹介されており、持っていた違和感の正体がわかりました。
意図的な技術的負債（短期）
戦術的または戦略的な理由による技術的負債。たとえば、時間的制約のあるリリースを期限までにデプロイするなど。
意図的な技術的負債（長期）
戦略的な理由による技術的負債。たとえば、最初からマルチプラットフォーム対応の設計と構築を行うのではなく、最初は１つのプラットフォームだけをサポートするなど。
不慮の技術的負債（悪意）
いいかげんなソフトウェア開発の習慣のせいで意図せずに発生する技術的負債。この種の技術的負債は将来と現在の作業を失速させるため、回避すべきである。
不慮の技術的負債（善意）
ソフトウェア開発がエラーと隣り合わせの性質であるために意図せずに発生する技術的負債。たとえば、「私たちの設計アプローチは思っていたほどうまくいかなかった」、「プラットフォームの新しいバージョンのせいで設計の重要な部分が無効になってしまった」など。
レガシーな技術的負債
新しいチームに引き継がれた古いコードベースの技術的負債。
推奨されるアプローチ
| 技術的負債の種類 | 推奨される対処法 |
|---|---|
| 意図的な技術的負債（短期） | ビジネス上やむを得ない場合は技術的負債を引き受け、すぐに返済する |
| 意図的な技術的負債（長期） | 必要であれば技術的負債を引き受け、返済を開始する条件を定義する |
| 不慮の技術的負債（悪意） | 作業習慣の質を高めることで、最初から技術的負債を作らないようにする |
| 不慮の技術的負債（善意） | この技術的負債は本質的に避けようがない。技術的負債の影響を監視し、「利子の支払い」が高くなりすぎたら返済する |
| レガシーな技術的負債 | 技術的負債を徐々に減らす計画を立てる |
チームとしてこの種類と対処法を共通理解し、技術的負債という言葉を使っていこうと思いました。
ブログはじめました
ブログはじめました
大学を卒業してからエンジニアになって早いもので13年経ちました。エンジニア、リードエンジニア、プロジェクトマネージャー、エンジニアリングマネージャーといろいろな役割を経験しました。これまでは、その経験の中で実践し、学習したこと、感じたエモい話は会社のナレッジツールに貯めていました。
21年の年の瀬でこれまでを振り返っていると、あれ？個人として学び、感じたことは、個人のアウトプットとして書いた方が良くね？と今更ながら思い、今回からブログとして残していくことに決めました。
なぜはてなブログか
候補として、Qiita, Note, Zenn がありましたが、技術的な話に限らず、個人的なことも書き残す可能性があり、収益につなげたいやバズらせたいという思いもないため、はてなブログで始めてみることにしました。 Gist にすることも考えましたが、カテゴライズして後でふりかえりたいのもあったので候補から外しました。 そんなこんなで、はてなブログで私がやったことやわかったことをオープンにしていく活動をゆるく初めていこうと思います。
