リファクタリング研修プロジェクト：技術的負債の軽減を教えるレガシーコード作業の構成方法

チームは、誰も完全に理解していない課金モジュールを引き継いだ。既存の動作を保証するテストも存在しない。そこで、「整理」のためのスプリントが提案され、コア部分を新しい構造で書き直す計画が立てられた。しかし、新しいバージョンでも顧客への課金が正しく行われることをどのように確認するのか、誰も説明できなかった。

これはあくまで例示であり、実際に起きた事例ではありません。リファクタリング研修プロジェクトが埋めるべきギャップ、つまり、コードが乱雑であることは認識できるものの、限定的な改善策を計画し、動作が維持されていることを示すことができないエンジニアの現状を説明しています。

このガイドは、エンジニアリングイネーブルメントリーダーおよびエンジニアリングマネージャー向けです。パフォーマンスの問題の記述方法、ギャップの診断方法、準備と実践の設計方法、ケーススタディの実施方法、そして習得したスキルが実際の業務に適用できるかどうかの評価方法について解説します。これはトレーニング設計に関するガイドです。プログラムで使用するコード、テスト、ルールは、自社の技術スタックでシニアエンジニアによる検証を受ける必要があります。

リファクタリング研修プロジェクトとは何ですか？

リファクタリング研修プロジェクトとは、既存コードを対象とした体系的な作業であり、コードの改善だけでなく、能力の向上も目的としています。受講者は、小規模で範囲を限定した変更を計画し、テストによって既存の動作を保護し、設計を段階的に改善し、何も問題がなかったことを証明します。コードが改善されるだけでなく、より重要なことに、エンジニアは実際の技術的負債に対処する際に必要となる判断力を養うことができます。

クイック事実

1. パフォーマンス上の問題点を説明する

まずは課題から始めましょう。既存コードの改善を計画し、検証するのです。「限定的」というのが重要なポイントです。学習者は、完了できるほど小さな変更を選択し、何が範囲に含まれ、何が範囲外かを明確に説明できるようになります。

用語を正確に定義することが重要です。マーティン・ファウラーはリファクタリングを次のように説明しています。 既存のコードベースの設計を改善するための制御された手法小さな、動作を維持する変換から構成される。「動作を維持する」というフレーズこそがリファクタリングと書き換えを区別するものであり、トレーニングで明確にする必要がある点である。技術的負債のメタファー自体 ワード・カニンガムによって造語されたまた、ファウラーの議論は、負債は意図的かつ慎重に負うことができるため、すべての厄介なモジュールが修正すべき間違いであるとは限らないということを改めて認識させてくれる有益なものである。

マイケル・フェザーズのレガシーコードに関する著書も、実践面で同様の立場をとっている。出版社の説明によると、この本は開発者に、以下のことを保証するテストの書き方を教えるという。 彼らは意図せずアプリケーションを変更しているわけではないそして、既存のソフトウェアを全面的に書き直すことなく、制御下に置くこと。

パフォーマンスに関する記述を1文で書き、エンジニアリングマネージャーに確認してもらいましょう。「既存のモジュールと明確な目標が与えられた場合、エンジニアは範囲を限定した変更を提案し、現在の動作を特定するテストを追加し、変更を小さなステップで実施し、動作が維持されることを示します。」

2. 学習と状況のギャップを診断する

何かを構築する前に、必要なタスクと、現在の活動で実践・評価している内容を比較してください。トレーニングのギャップとそれ以外の問題を区別する上で、通常、次の3つの質問が役立ちます。

1. 現在の実践は、実際の課題に基づいているか？ 研修でスライドを使ってリファクタリングパターンを解説しても、テストされていないコードを変更する人がいなければ、誰も保護動作を実践したとは言えません。評価がコードの臭いに関する多肢選択式テストであれば、それは記憶力しか測っていないことになります。
2. 認知的な要求とは何ですか？ ブルームの改訂版分類法では、変更が安全かどうかを判断することは分析と評価のレベルに、計画とテストを設計することは創造のレベルに該当します。これらのレベルにアクティビティを対応させる方法については、ガイドで説明しています。 学習活動をブルームの分類法に合わせる.
3. スキル以外の何かが妨げになっているのでしょうか？ 人員配置、ツール、手順を確認してください。ビルドに1時間かかるようでは、誰も頻繁にテストを実行しません。メンテナンス作業がスケジュールされないようでは、エンジニアはこっそりとリファクタリングを行うだけです。トレーニング以外の原因については、それを解決できる担当者に報告してください。

3. 目的意識を持った準備と練習を計画する

トレーニングによって埋められるギャップが分かったら、各段階に明確な役割を与えましょう。

準備。 簡単な診断テストで前提条件を確認しましょう。テストフレームワークの仕組み、特性評価テストとは何か、チームでのレビューとマージの手順などを確認します。この段階では、自分のペースで学習を進めるのが適しています。復習テストでは、前提条件の確認のみを行います。

練習。 明確な形を持つ体系的なリファクタリング プロジェクトを使用します。小さく安全なサンプルから始め、次に実際のコード ベースの限定された部分に進みます。Gilded Rose カタは、最初のステップの出発点としてよく知られています。その README は Emily Bache によって管理されています。 コードを変更する前にテストを書くことを推奨します そして、この取り組みを、小さなステップを踏み、頻繁にテストを実行し、設計を少しずつ改善していく練習として捉えています。各プロジェクトにおける適切な手順は次のとおりです。目標と範囲を定義し、現在のコードの動作を捉えるテストを作成し、一度に1つのことだけを変更し、各ステップの後にテストを実行し、学んだことを書き留めます。

フィードバック フィードバックは総合点ではなく、決定事項に結び付けましょう。「割引ロジックは抽出できましたが、テストは正常系のみを対象としていたため、丸め処理の変更に気づけなかった可能性があります」という方が、「5点満点中3点」よりもずっと有益です。

講師によるリアルタイムの指導か、非同期の復習か？ ライブ入力は、例えば、途中で止めて不足しているテストを追加するか、そのまま続けるかなど、選択肢が曖昧な場合に最も効果を発揮します。学習者が自分の計画やテストを注釈付きの専門家版と比較する場合は、非同期レビューで十分です。多くのチームは両方を活用しています。まずは各自のペースで準備を進め、その後、難しいケースについてファシリテーター付きのセッションを行うという方法です。

4. 現実的な例題に取り組む

例示です。エンジニアリングマネージャーは、使用前に事例と回答基準を検証する必要があります。

ケース。 既存の関数は、割引、税金、配送ルールを含めた注文合計金額を計算しますが、テストがありません。そこで、チームは請求モジュール全体を再構築して「より簡潔」にすることを提案しました。

その任務。 学習者は、自分が何をするかを説明し、収集する証拠を挙げ、さらにどのような情報や支援が必要かを述べる。

最初の試み。 「モジュールを3つのサービスに分割してロジックを移動し、ステージング環境で数値をチェックします。」学習者は大規模な変更と、後から手動でチェックするという方法を選択した。旧バージョンと新バージョンがエッジケースで一致するかどうかを確認する方法はない。

フィードバックと再試行。 レビュー担当者は、空のバスケット、合計金額がマイナスになる割引、および丸め処理の場合に、この関数が現在どのような動作をするかを尋ねます。再テストでは、学習者に動作の範囲を1つに絞り込み、その動作が変わっていないことをどのように証明するかを述べるよう求めます。

より強力な試み。 「モジュール構造は今のところそのままにしておきます。まず、注文合計関数が、エッジケースを含む一連の入力に対して現在返す値をテストとして取得します。次に、割引計算を独自の関数に抽出し、その単一のステップの後にテストを実行して停止します。配送ルールには理解できない動作があるため、変更を加える前に同僚に確認します。」この回答では、変更の範囲を限定し、まず動​​作を保護し、不明な点を明確にしています。

それぞれの回答が妥当である理由、あるいは不完全である理由。 それぞれの評価は、審査員の好みではなく、承認された基準に基づいて行うべきである。最初の試みは、長期的な方向性としては妥当かもしれないが、行動様式が維持されている証拠がないため、計画としては不完全である。より優れた試みは、規模が小さく、検証可能であり、不確実性について正直である。

5．能力を評価し、移転計画を策定する

能力の証拠は、学習者が見たことのない新しいレガシーコードのケースにおけるパフォーマンスです。リスク分析と、行動が維持された証拠を評価します。シンプルなルーブリックでは、各基準に対して0～2の尺度を使用します。

アンカー: 0 は存在しないかサポートされていない、1 は関連する省略がある部分的、2 は合意された基準に対して完全かつ正当化されている。テストで検出されない動作変更など、重大なエラーは個別に定義し、全体的なスコアで隠蔽できないようにします。この評価基準は提案であり、検証済みの準備標準ではありません。エンジニアリング マネージャーと調整し、パイロット運用してください。 有益なフィードバックを伴うインタラクティブな実践を設計する 意思決定につながるフィードバックの書き方を示します。

計画的に移行を進めましょう。演習後、各エンジニアに小さな実際の課題を与え、レビュー担当者と話し合う機会を設けたり、最近発生した変更で問題が発生した箇所について簡単な振り返りを実施したりします。移行状況の確認は、ワークショップ直後ではなく、実際の業務に適切な形で触れさせた後に行いましょう。

インタラクティブな配信が役立つ場面

インタラクティブな形式は、グループ全体を見る前に全員が自分の意見を表明する必要がある場合に役立ちます。ライブセッションでは、ファシリテーターが短い既存コードの断片を示し、各エンジニアに最初に行う変更とその安全性の証明方法を提出させ、その後、議論の前にその内容を公開することができます。同じ課題を、各自のペースで準備を進めるために実行することも可能です。 AhaSlides インタラクティブな学習と、ライブ配信と自己ペース配信の切り替えをサポートします。これはプレゼンテーションと学習のためのツールであり、コードを実行または分析する場所ではないため、リファクタリング自体は独自の環境で実行してください。使用する予定の特定のオーサリング、フィードバック、またはレポート機能は、独自のワークフローと照らし合わせて確認してください。フォーマットの選択に関するガイダンスについては、次の記事を参照してください。 適応型学習、インタラクティブ学習、ライブ学習をいつ活用するか.

何が変わったかを測定する

エンジニアがタスクを実行できることを示す指標を事前に決定してください。リスク分析の質と、未知のケースにおける適切な動作の証拠を、基準値と比較します。対象者、分母、およびタイミングを明確に定義してください。結果が改善した場合は、トレーニングの効果を評価する前に、新しいテストツール、ビルドの高速化、所有者の変更など、同じ期間に他に何が変わったかを確認してください。

残る可能性のある制約

• メンテナンス作業の時間です。 債務処理業務が全く予定されなければ、訓練を受けた技術者はそのスキルを活かす場所がないままになってしまう。
• テストツール。 実用的なテストハーネスや迅速な組み立て方法がなければ、小さなステップと頻繁なチェックを継続するのは難しい。
• 事件報道。 ある過去の事例は、いくつかの種類のリスクを示している。スコアは、エンジニアの判断力を一般的に表すものではない。
• リファクタリングを行うべきでない時を判断する。 コードによっては、そのままにしておく方が良いもの、置き換える方が良いもの、あるいは廃止する方が良いものがあり、その判断にはスキル以上の要素が関わってくる。
• 転送。 カタにおけるパフォーマンスは、納期プレッシャーのかかる生産モジュールにおけるパフォーマンスとは異なる。

これらの問題点を早めにスポンサーに伝え、個別の対策を計画しましょう。研修は、エンジニアが計画し、実証できる能力を向上させますが、時間やツールを生み出すものではありません。

よくある質問

リファクタリング研修プロジェクトとは何ですか？

これは、既存コードに対する体系的な実践方法であり、エンジニアは小さな変更を計画し、テストによって既存の動作を保護し、設計を小さなステップで変更し、何も問題が起こっていないことを示す。

全面的な書き直しは、技術的負債について学ぶ良い方法でしょうか？

通常はそうではありません。コードの書き換えは規模が大きく、検証が難しく、構築したいスキルを隠してしまうからです。現在の動作を捉えるテストを伴う限定的な変更であれば、その根拠を明確に示すことができます。

エンジニアが安全にリファクタリングできるかどうかをどのように評価しますか？

新たな既存コードの事例を提示し、リスク分析と、合意された基準に照らして動作が維持されたことを示す証拠を評価してください。リファクタリングパターンに関するクイズは、前提条件の確認のみを目的としています。

トレーニング用のサンプルコードベースが必要ですか？

安全に練習できる場所が必要です。多くのチームはまず公開されているカタ（練習課題）から始め、その後、自分たちのコードの範囲内で練習を進めます。エンジニアリングマネージャーは、そのコードが適切であることを確認する必要があります。

どこから始めれば

コードベース内で、小規模で繰り返し発生するレガシー変更を1つ選びます。パフォーマンスに関する記述を作成し、エンジニアリングマネージャーにケースと、変更後の動作が維持されることを示すテストを検証してもらいます。そして、0～2のスケールと重大なエラーのリストを含む3つの評価基準からなるルーブリックを作成します。展開する前に、少人数のグループでパイロットテストを実施してください。

リファクタリングの意思決定演習を自社チームで実際に実行し、その後は各自のペースで再利用する方法を確認するには、以下をご覧ください。 AhaSlides.