システムの技術的負債にどう挑むか？～『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策～

2024年1月16日(火)に開催したオンラインセミナー「システムの技術的負債にどう挑むか？～『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策～」のスライド資料です。

【セミナー概要】
企業の規模や業界に関係なく、開発したソフトウェアやシステムが成長するにつれて生じるのが「技術的負債」にまつわる課題です。
新たな機能や変更が追加され、コードが複雑化することにより、保守や拡張が難しくなるだけでなく、競争力の低下やセキュリティの脆弱性の増加といった問題を招く可能性もあります。
このような問題に対して、IT部門を中心に企業はどのようなアクションを起こすべきでしょうか。

本セミナーでは、複雑化したコードに対する具体的な分析・対処方法を解説し、多くの人に読まれている『レガシーコード改善ガイド』著者のマイケル・フェザーズ氏が、企業に想定される課題と、実践的な解決策について詳しくお伝えします。

【スピーカー】
マイケル・フェザーズ氏　Michael Feathers
ソフトウェアと組織設計を専門とするR7K Research & Conveyance社の創設者兼ディレクター。R7K設立以前は、Obtiva社のチーフ・サイエンティスト、Object Mentor International社のコンサルタントを務める。これまで20年以上にわたり、何百もの組織とコンサルティングを行い、ソフトウェア設計の問題、プロセスの変更、コードの活性化を支援している。著書に『レガシーコード改善ガイド』（翔泳社）。

Transcript

2. Michael Feathers Founder, R7K Research & Conveyance The Challenge of Technical Debt 技術的負債の課題
3. History 歴史 • A metaphor in common use よく使われる比喩 Technical Debt 技術的負債 •Analogous to debt in finance 金融における負債との類似性 •Debt can allow you to deliver quickly but its costs increase over time. 負債は迅速に資金を調達で きるが、そのコストは時間とともに増大する。 •Debt, when used, should be used strategically 負債は戦略的に使われるべきである。
4. History 歴史 • Today we have expanded the notion of debt in software development 今日、私たちはソフトウェア開発における 負債の概念を拡大した "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."[12] —Ward Cunningham, 1992 「初めてのコードを納品するということは、借金をするようなものだ。少々の借金は、それが書き換えによって速 やかに返済される限り、開発を加速させる......。危険なのは、借金が返済されないときだ。正しくないコードに 費やされた時間はすべて、借金の利息としてカウントされる。エンジニアリング組織全体が、オブジェクト指向で あろうとなかろうと、統合されていない実装の負債の負荷の下で停止状態に陥る可能性がある」[12]。 - ウォード・カニンガム、1992
5. The Issue of Naming ネーミングの問題 • Whenever we introduce a term for a specific thing and there is no name for the general, the general uses the specific name • 特定のものを指す言葉を用いるとき、一般 的なものの名前がなければ、一般的なもの は特定の名前を用いる。 •People are using Technical Debt to mean any time of complication or ugliness in code 技術的負債（Technical Debt）とは、コードの複雑さや汚さを意味する。 •The term is also used for things outside of the code (process, architecture, infrastructure) この用語は、コード以外のもの（プロセス、アーキテクチャ、インフラ）にも使われる。
6. The Common Idea 共通の考え • There is a distance between the state you are in and the state you want to be in. • 今いる状態となりたい状態の間には距離が ある。 •The current state lags behind the ideal state 現在の状態は理想的な状態に比べて遅れている •What do we know about this ideal state? 理想的な状態について私たちは何を知っているのか？
7. Software Ideals ソフトウェアの理想 • There are many opinions about what is good in software development • ソフトウェア開発において何が優れている かについては、多くの意見がある。 •The main goal is ease of change 主なゴールは変化のしやすさ •In order to have ease of change we must have ease of understanding 変更を容易にするためには、理解を容易にしなければならない
8. Good Code 良いコード
9. Path Dependence 経路依存性 •Each state we leave our code in is a starting point for the next 私たちがコードを残すそれぞれの状態は、次の状態への出発点となっている。
10. Path Dependence 経路依存性 •Each state we leave our code in is a starting point for the next 私たちがコードを残すそれぞれの状態は、次の状態への出発点となっている。 The Notion of Responsibility 責任の概念
11. Path Dependence 経路依存性 • New growth in systems rarely replaces what comes before システムに おける新たな成長は、以前のものと置き換わることはほとんどない • It is more common that it is an addition 追加されることの方が多い • It is more like nature, biology 自然や生物学に近い
12. Organic Growth オーガニックグロース、有機的成長 • This is the way that systems grow これがシステムの成長である。 • We add and often the thing that we add goes its own way 私たちは追加 し、多くの場合、追加したものは独自の道を歩む。 • It falls out of harmony with the existing structure 既存の構造との調和から 外れてしまう • This happens in a things that grow over time. • Software • Buildings • Cities これは、時間とともに成長するものの中で起こることだ。 • ソフトウェア • 建物 • 都市
13. The Cost of Incremental Change インクリメンタルな変更のコスト • Non-holistic change leads to disintegrity ホリスティックではない（非全体的な）変 化は崩壊を招く •The only way we can change the whole holistically is to replace it 全体を総合的に変えるには、システムをリプレースするしかない。 •To keep systems in integrity when we change them incrementally, we must refactor 漸進的にシステムを変更する際に、システムの整合性を保つためには、リファクタリングが必要である。
14. Understanding Change in Systems システムの変化を理解する
15. 0 100 200 300 400 f i l e s # of commits Clojure
16. 0 75 150 225 f i l e s # of commits Fitnesse
17. 0.0 17.5 35.0 52.5 70.0 f i l e s # of commits JUnit
19. 0.0 7.5 15.0 22.5 30.0 time A Method Lifeline
21. repo.commits.map {|c,_| repo.commit(c).added_complexity.to_i } Added Complexity Over Time 時間の経過とともに複雑さが増す
22. The Trending View トレンドの観点
23. Methods Ascending 昇順のメソッド
24. Trending Methods トレンドのメソッド
25. Classes By Closure Date 終了日ごとのクラス [["DummiesController", 2008-04-21 13:03:08 -0700], ["Core::ActiveRecord::AttributeDefaults::ClassMethods", 2008-04-22 16:02:54 -0700], ["Legacy::Database", 2008-04-24 15:37:51 -0700], ["Core::ActiveRecord::AttributeDelegation::ClassMethods", 2008-04-24 20:46:58 -0700], ["Core::ActiveRecord::SkipValidationForHasOnes", 2008-04-29 21:54:32 -0700]]
26. Classes By Closure Date 終了日ごとのクラス
27. Temporal Correlation of Class Changes クラスチェンジの時間的な相関関係 [[["App", "Inventory"], 277], [["Inventory", "Object"], 216], [["Admin", "Inventory"], 195], [["Inventory", "User"], 188], [["Inventory", "Users"], 171], [["Inventory", "Deals"], 167], [["App", "Object"], 159], [["App", "InventoryController"], 152], [["Inventory", "Order"], 149], [["User", "Users"], 149], [["App", "User"], 143], [["Inventory", "InventoryController"], 143], [["Api", "Inventory"], 141], [["Admin", "App"], 136], [["Campaign", "Orders"], 134]]
28. Temporal Correlation of Class Changes クラスチェンジの時間的な相関関係
29. Temporal Correlation of Class Changes クラスチェンジの時間的な相関関係
31. Active Set of Classes
32. Active Set of Classes
33. Technical Debt - the amount of effort it takes to refactor your code to make it easy to add the next feature non- invasively. 技術的負債とは、次の機能に影響を与え ずに簡単に追加できるようにコードをリ ファクタリングするのにかかる労力のこ とである。
34. Closure is Vital クロージャは重要
35. Closure and Responsibilities クロージャと責 任 • When entities are focused on one thing, closure comes naturally エンティティが一つのことに焦点を当てて いると、クロージャは自然に生まれる。 •It can be hard to see responsibilities 責任は見えにくいことがある •Sometimes we see them through change characteristics 変化という特性を通して見ることもある •Seeing them can be a team practice 見ることはチームのプラクティスになる
36. Practices 実践
37. Design Decision Records 設計決定の記録 Practice Maintain cards for each of the design decisions you make that you may consider revisiting someday. Periodically re-estimate them to consider feasibility 再検討する可能性のある、設計上の決定ごとに カードを管理する。 定期的に再見積もりを行 い、実現可能性を検討する。
38. Feature Trend Records 機能トレンドの記録 Practice Hypothesize a couple of features that you will never add to your code. Task them and estimate them periodically. See the debt trend for areas they touch. コードに絶対に追加しない機能をいくつか仮定す る。 それらをタスク化し、定期的に見積もる。 それらが影響を与える部分の負債の傾向を見る。
39. Scratch Refactoring スクラッチ・リファクタリング Practice Refactor massively in an editor. Emphasize extractions, and moves. Don’t worry about compilation. Never check it in. Use the experience to explore エディターで大量にリファクタリングする。（メ ソッドの）抽出と（クラスの）移動を重視する。 コンパイルは気にせず、 決してチェックインし ない。 経験を探求に活かす。
40. Suggestive Refactoring 提案型リファクタリング Practice Create small refactoring stories based upon and add them to the backlog 小さなリファクタリングストーリーを作成し、 バックログに追加する。
41. Split Prep-Refactorings 分割準備リファクタリング Practice Highlight refactoring within a team by making it a separate task done by different people. The handoff forces discussion チーム内のリファクタリングは、別の人が行うタ スクにすることで目立たせる。引き継ぐことで議 論が生まれる。
42. Privileged Abstractions 特権的な抽象化 Practice Select the abstractions that you consider primary in the system and document them. Have conversations around them システムの中で主要と思われる抽象的なものを選 び、文書化する。 それらについて会話する。
43. Limited WIP Refactoring 制限されたWIPのリファクタリング Practice Never have more than 1 or 2 large scale refactorings in progress at once. This forces focus and emphasizes completion 一度に1つか2つ以上（複数）の大規模なリファク タリングを進めてはならない。1つのリファクタ リングに集中することにより、確実に完了するこ とができる。
44. Architectural Mapping アーキテクチャのマッピング Practice Diagram the system you are working as it were the terrain of an old country. Document the dragons. Have a common team vision of the place where the best code resides 取り組んでいるシステムを、古い国の地形のよう に図解する。ドラゴン（特に気をつけないといけ ない部分）を文書化する。 最高のコードが存在 する場所について、チーム全体で共通のビジョン を持つ。
45. Silent Alarms サイレントアラーム Practice Don’t have check-in gates. Let people make mistakes. Investigate the mistakes off-line and see why they happened. Then, intervene チェックイン・ゲートを設けない。ミスをさせ る。そのミスをオフラインで調査し、なぜ起こっ たかを確認する。 その後、介入する。
46. Direction Tagging 方向性のタグ付け Practice Create tags for areas that need work. Embed them in the code. They do not go stale as comments do. Tackle them in a limited WIP manner 作業が必要な部分のタグを作る。それをコードに 埋め込む。タグは（作業内容を含まないので）コ メントのように陳腐化しない。限定的なWIPのや り方で（すべてのタグを一度に処理しようとせ ず、1つずつ処理する方法で）取り組む。
47. Transparent Design Quality 透明性のある設計品質 Practice
49. Conclusion まとめ •Technical Debt is a lag between the current state and an ideal state for the current time 技術的負債とは、現在の状態と、その時点における理想的な状態との間に生じる遅れのことである。 •It is a side-effect of natural patterns of growth 自然な成長パターンの副作用である •Our ideal state is: understandable and easy to change with integrity 理想的な状態とは：理解しやすく、整合性をもって変更しやすい状態 •Avoiding Technical Debt requires socialization of practices 技術的負債を回避するには、プラクティスを一般化する必要がある