【セミナー資料・質疑応答まとめを公開！】「システムの技術的負債にどう挑むか？～『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策～」
ITプレナーズは2024年1月16日（火）に、ウェビナー「システムの技術的負債にどう挑むか？～『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策～」を開催しました。
本ウェビナーでは、複雑化したコードに対する具体的な分析・対処方法を解説し、多くの人に読まれている『レガシーコード改善ガイド』著者のマイケル・フェザーズ氏を迎え、技術的負債とはなんなのか、そして実践的な解決策について詳しくお話しいただきました。また、講演後の質疑応答では、参加者の皆様からたくさんの質問が寄せられました。当日の講演資料や、質疑応答の内容をご紹介します。
講演資料
質疑応答の内容紹介
質問1
——Split Prep-Refactoring（分割準備リファクタリング）を行う際に、機能追加のコーディングからリファクタリングまでは時間を空けない方が良いでしょうか？
時間はあまり空けない方が良いです。なぜかというと、このプラクティスの主な価値は、これによって生じる2人のコミュニケーションだからです。2人ですると、1人の作業量が非常に軽く、もう1人の作業量が重いということが実感できると思います。このSplit Prep-Refactoringは、リファクタリングをしっかり時間をかけて行うことでその後の機能追加が格段に短い時間で済むということを実感してもらうためのものなので、それが実感できたら続ける必要はありません。
質問2
——適切と思えない実装でも、期待した動きをしてしまうことがあると思いますが（だからこそプログラミングが難しいと感じることもあります）、どう検証すると良いのでしょうか？
全てのコードの部分が同じように変更されるということはありません。コードの中には、機能はしているものの、書き方に問題があって理想的な形ではないものがあるかもしれません。ですが、そのコードに頻繁に変更がかかっていなければ、多少書き方がまずくてもあまり気にしなくていいと思います。
ただ、頻繁に変更がかかるコードである場合は、そのコードがわかりやすいものである必要があります。もちろんコードベース全体が明確であり、クリーンであるというのが理想ですが、リファクタリングする際に全てのコードをわかりやすいように書き換えなければいけないというわけではありません。
また、このコードの構造を大々的に変えるような大規模なリファクタリングと日常的なリファクタリングは別に考えます。大規模なリファクタリングというのは戦略的に行うものです。そして、小さなリファクタリングというのは、ここの部分を変えたいとか、より理解したいという部分に行います。つまり機能するシステムを作るためにすべてを同等に変更する必要はないのです。
質問3
——Limited WIP Refactoring（制限されたWIPのリファクタリング）で「複数の大規模なリファクタリングを進めてはならない」とありましたが、ときどき「上司（ビジネス側）の許可が得られず、大規模なリファクタリングができない」という話も聞きます。このように、なぜか「リファクタリングは後でまとめて計画的に大規模に行うもの」と思い込んでいる組織へのアドバイスはありますか？
私が直接そのビジネス側の方々とお話しできるようにしていただけたらいいですね（笑）
第一に、まず開発部門とビジネス側に信頼関係があるということが非常に重要です。
そして、テストが自動化されるというのもとても重要です。より良い自動化されたテストがあれば、自信をもってリファクタリングができて、それほどリファクタリングが怖いものではなくなります。テスト自動化によって、リファクタリングやシステムに変更をかけることだけでなく、機能追加もより迅速になります。
質問4
——「変更のしやすさ」と「理解のしやすさ」について言及されましたが、例をいくつか挙げていただけますか？これらは厳密にソースコードに限定されるのでしょうか？
ソースコードだけでなく、企業にも同様の課題が存在します。たとえば、全員が同じプロセスである場合、変更が難しくなります。全員に新しいやり方を理解してもらい、変えさせる必要があるためです。しかし、企業を全体ではなく複数のグループに分け、各グループが異なるやり方やポリシーを採用することで、変更が容易になります。細かく分割することは必ずしも良いとは言えませんが、これにより変更の柔軟性が向上します。ただ、すべての変更が容易であるべきというわけではなく、もちろん変更が難しい場合もあります。セミナーで話した「Design Decision Records（設計決定の記録）」を導入することで、後々コードや意思決定を変更する際の難易度が把握できます。
長期にわたってソフトウェア開発をしていると、コードにまつわる動きというのは自然現象や世の中の他の仕組みと非常に似ているということがわかります。また、ソフトウェア開発の経験によって、システム思考も培われていきます。
質問5
——「抽象度を揃えるべき」ということは理解できますが、抽象度を比較するのは難しいと感じています。主観的になってしまい、納得感が得にくいです。コードレビューのときに、どのように説明すると良いでしょうか？
重要なのは「責任」という概念です。コード内で変更が必要な部分が何で、それがどのような役割や責任を果たしているのかを明確にすることです。これはシステム全体で行えるアプローチで、例えば、ある関数が計算を実行し、その結果をプリントする場合、コードを見ないで尋ねられたら、その人は単にレポートをプリントしていると答えるでしょう。ただし、開発者ならば、同じ関数がレポートをプリントするだけでなく演算も同時に行っていることが分かるはずです。これらは別々に変更できます、例えばレポートのフォーマットを変更せずに演算の部分だけを変更できますし、逆に演算を変更せずにレポートのフォーマットだけを変更することも可能です。ただし、これらがまとめられていると非常に複雑になります。
このような認識を共有することで、お互いに納得しやすく、合意に達することができます。私たちはシステムの見方を話しており、これによってシステムを今後どのように改善できるかが考えられます。
ただし、私の経験では、議論が始まるとみんな疲れてしまい、何かしらの合意に収束します。
質問6
——リファクタリングの手法やアプローチは、使用しているプログラミング言語に依存することはありますか？
ある程度はプログラミング言語に依存することはありますが、基本的には現在のコードを複数のパートに分解し、それを再び統合させる作業です。ただし、動的言語と静的言語では少しやり方が異なる部分もあります。また、言語の種類によってはリファクタリングが少し簡単になる場合もあれば、逆に難しくなる場合もあります。これらの情報によっては、どの言語を使ってリファクタリングを行うかの意思決定にもつながると考えています。
——クラスベースのC＃のような言語とJavaScriptのような言語ではアプローチに違いはありますでしょうか。
違いはありますね。JavaScriptなどの言語はプロトタイプの性質があるため、リファクタリングが少し複雑になってしまう傾向があります。ただし、C#にもC#なりの課題や難しさがあります。
マイケル・フェザーズ氏のトレーニングのご紹介
ITプレナーズは、今回のセミナーでスピーカーとして登壇したマイケル・フェザーズ氏が
講師を務める2日間の研修を、日本語通訳付き・集合研修（東京）で開催します。マイケル・フェザーズ氏のトレーニングが日本で受講できる貴重な機会ですので、ぜひご参加ください。
コース名：実践！技術的負債の克服テクニック ～ワークショップ形式でマイケル・フェザーズ氏から直接学べる2日間～
開催日程：2024年6月6日(木)-7日(金) (2日間) (申込期日：4/23(火))
講義時間：9:30 – 18:00 (開場 9:00)
開催方法：集合研修のみ
会場：東京都千代田区六番町 1-7 Ohmae@workビル 地下1階（Google Map）
講義言語：英語・日本語 ※日本語通訳あり
受講費用：275,000円(税込)