https://www.ogis-ri.co.jp/otc/hiroba/technical/code-quality-kaizen-pattern/
ソースコードを漸進的に改善するための組織的活動のパターン・ランゲージを作りました。リファクタリングはソースコードの改善テクニックですが、ソースコードの品質改善活動を成功させるためにはリファクタリングだけでは足りません。品質改善を利害関係者も含めたチームの活動として捉えることが必要です。このソースコード品質改善パターンを参考にしてソースコードの品質改善を成功させてください。
筆者は、製造業の組込みソフトウェア開発チームに対してプロセス改善や技術支援のコンサルティングを行っています。そのコンサルティングの中で、ソースコードの品質を漸進的に改善することに成功したチームに共通するコツのようなものをパターン・ランゲージとしてまとめたものが、このソースコード品質改善パターンです。
まだ、数チームの事例分析に基づくものなのでパターン・ランゲージとして練りきれていないところがあるでしょう。そのため、このパターン・ランゲージは適用できる範囲が狭い恐れがあります。ですが、下記のような状況の開発チームにおいては、参考になるパターン・ランゲージであると考えています。
パターンについては、私の下記の記事を参考にしてください。
ソースコード品質改善パターンの全体像を下図に示します。パターン・ランゲージの読み方については、私が以前に書いた「パターン・ランゲージを使ってチームの問題を解決する方法をデザインする」を参考にしてください。
なお、このパターン・ランゲージは、James O. Coplien氏らによる「組織パターン」から「アーキテクチャチーム」と「缶詰」パターンを拝借し、筆者オリジナルのパターンと組み合わせて作成したものです。
パトレットとは、パターンの要約の事です。パトレットを用いてパターンの一覧を下記にまとめました。
| パターン名 | 要約 |
|---|---|
| 全ての関係者の理解 | どれくらいのムダが発生しているかの認識を利害関係者間で共有し、ソースコードの品質改善を開始することの理解を得る |
| 課題の可視化 | ソースコードの課題を特定してそれを共有し、関係者全員が同じ認識を持つようにする |
| アーキテクチャチーム | 最初のアーキテクチャを作る責任と権限を持ったチームを作ろう |
| 缶詰 | アーキテクチャを考え出すチームが苦労しているなら、何日間か物理的に他から隔離して、邪魔されずに作業できるようにしよう |
| 将来像 | 目指すべきアーキテクチャの将来像を定める |
| 実験室 | 実際の業務やプロダクションコードに影響のない環境を用意し、将来像の試行錯誤やエンジニアの教育をする |
| 安全装置 | 既存のソースコードをテストする環境を用意してからソースコードを変更する |
| ものさし | ソースコードの変更が将来像に合っているかをチェックする仕組みを構築する |
| 業務に組込む | リファクタリングを開発チームの努力やモラルのみに頼らず、組織として活動を進める |
| 漸進的成長 | リスクの面からもコストの面からも少しづつ進めるほうが妥当な判断ができる |
以下が、パターン一つ一つの説明です。
