2024/10/7
laprasdrum.icon 週明けから少しバテ気味
/icons/hr.icon
Explicity Built Module
キャッチアップから漏れてたが、ビルド時間の改善によさそう。
Martin Fowler本人によるRefactoring解説
https://www.youtube.com/watch?v=CjCJ76oZXTE
1. リファクタリングの起源と重要性
詳細解説:
1990年代半ば、ソフトウェア業界では、コードの変更は非常にリスクの高い作業とみなされていました。開発者たちは、コードを「コンクリートを注ぐ」ように不変のものとして扱っていました。この考え方は、長期的なプロジェクトや変化する要件に対応する上で大きな障害となっていました。
Martin Fowlerは、Kent Beckとの協働を通じて、小さな変更を積み重ねることで大きな改善が可能であることを発見しました。これがリファクタリングの核心です。リファクタリングは、既存の機能を変えることなくコードの内部構造を改善する過程です。
この手法は、ソフトウェア設計に対する考え方を根本的に変えました。開発者たちは、初期段階ですべてを完璧に設計する必要がなくなり、代わりに継続的に設計を改善することができるようになりました。これにより、ソフトウェアの柔軟性と適応性が大幅に向上しました。
Fowlerは、この概念を広めるために「リファクタリング」の本を執筆しました。彼は、自身のリファクタリング経験を詳細に記録し、それを体系化することで、他の開発者がこの手法を学び、実践できるようにしました。
2. テストの重要性
詳細解説:
Fowlerは、リファクタリングにおけるテストの重要性を強く強調しています。テストは、リファクタリングの安全性を保証する鍵となります。
テストがない場合、開発者はコードの変更が既存の機能を損なっていないかを確認する手段を持ちません。これは、リファクタリングを危険で非効率的なプロセスにします。
一方、適切なテストスイートがある場合、開発者は自信を持ってコードを変更できます。テストは、変更後も全ての機能が正しく動作していることを即座に確認する手段を提供します。
Fowlerは、「自己テスト可能なコード」の概念を紹介しています。これは、各クラスや部品が自身をテストする能力を持つべきだという考え方です。この方法により、開発者はコードの変更後すぐに問題を検出し、修正することができます。
さらに、テストは単なるバグ検出ツールではありません。それは設計ツールでもあります。テストを書くことで、開発者はコードの使用方法や期待される動作を明確に定義することができます。これは、より良い設計決定につながります。
はい、引き続き詳細な解説を提供します。
3. エクストリームプログラミング（XP）との関連
詳細解説:
リファクタリングは、エクストリームプログラミング（XP）という広範なソフトウェア開発手法の重要な要素の一つです。Fowlerは、XPの他の実践がリファクタリングを効果的にサポートすることを説明しています。
XPの主要な実践には以下が含まれます：
- 継続的インテグレーション：頻繁にコードを統合することで、問題を早期に発見し、修正できます。
- 自己テスト可能なコード：各部分が自身をテストする能力を持つことで、変更の影響を即座に確認できます。
- テスト駆動開発（TDD）：テストを先に書くことで、設計の質が向上し、リファクタリングがより安全になります。
- ペアプログラミング：二人で作業することで、リファクタリングの機会をより早く識別し、実行できます。
これらの実践が組み合わさることで、開発者はコードを常に改善し続けることができます。Fowlerは、これらの実践を「エンジン」と表現し、ソフトウェアを成長させ、進化させる力を生み出すと説明しています。
XPの哲学は、変更を恐れるのではなく、変更を歓迎し、それに適応する能力を築くことです。リファクタリングはこの哲学の中心的な実践であり、コードベースを常に最適な状態に保つためのツールとなります。
4. 信頼の重要性
詳細解説:
Fowlerは、ソフトウェア開発チーム内の信頼の重要性を強調しています。信頼は、アジャイル開発やXPの成功に不可欠な要素です。
信頼の重要性は以下の点で顕著です：
- コードの共同所有：チームメンバーが互いのコードを自由に修正できるためには、高い信頼関係が必要です。
- 透明性：問題や課題を隠さずに共有するためには、チーム内の信頼が不可欠です。
- 迅速な意思決定：信頼関係があれば、意思決定プロセスが迅速化され、開発速度が向上します。
- リスクテイキング：新しいアイデアを試すためには、失敗を恐れない環境が必要であり、これには信頼が重要です。
Fowlerは、信頼を構築することが、ソフトウェア開発プロセスから多くの摩擦を取り除くと説明しています。例えば、信頼があれば、過度の文書化や厳格な承認プロセスなどの「企業統制」が不要になる可能性があります。
しかし、信頼の構築は容易ではありません。特に大規模な組織では困難を伴います。Fowlerは、透明性の確保、共同作業の奨励、テストの重視などが信頼構築に寄与すると提案しています。
5. 本とオンラインコンテンツの役割
詳細解説:
Fowlerは、開発者教育における本の役割と、オンラインコンテンツとの関係について深い洞察を提供しています。
現代のデジタル時代では、短形式のコンテンツ（ツイート、ブログ記事、ビデオなど）が主流となっています。しかし、Fowlerは、これらの短形式コンテンツだけでは、複雑な概念や深い理解を得るには不十分だと指摘しています。
本の利点：
- 深い没入：本は読者に長時間集中する機会を提供し、複雑な概念を十分に探求できます。
- 構造化された学習：本は通常、論理的に構造化されており、アイデアを段階的に理解するのに役立ちます。
- 永続的な参照：本は長期間にわたって参照できる信頼性の高いリソースとなります。
一方で、Fowlerは本の限界も認識しています：
- 出版に時間がかかる
- 更新が難しい
- 場合によっては必要以上に長くなる傾向がある
そこで、Fowlerは30-50ページの長文記事という中間形態を提案しています。これらは：
- 本ほど長くないが、十分に深い内容を扱える
- オンラインで公開でき、更新が容易
- 特定のトピックに焦点を絞ることができる
Fowlerは、自身のウェブサイト（martinfowler.com）でこのアプローチを実践しており、5年以上前の記事が今でも多くのトラフィックを集めていることを指摘しています。これは、十分な深さと永続的な価値を持つコンテンツの重要性を示しています。
6. 「ベストプラクティス」vs「適切なデフォルト」
詳細解説:
Fowlerは、ソフトウェア開発業界でよく使用される「ベストプラクティス」という用語に対して懐疑的な立場を取っています。代わりに、彼は「適切なデフォルト（sensible defaults）」という概念を提案しています。
「ベストプラクティス」の問題点：
- 絶対的な正解を示唆してしまう
- コンテキストや状況の違いを考慮していない
- 改善や革新を妨げる可能性がある
「適切なデフォルト」の利点：
- 柔軟性を認めている
- コンテキストに応じた適応を促す
- 継続的な改善と学習を奨励する
Fowlerの考えでは、「適切なデフォルト」は開発者に出発点を提供しますが、それを無批判に受け入れるのではなく、自分たちの状況に合わせて調整することを奨励します。これは、ソフトウェア開発の複雑さと多様性を認識し、常に学習と適応を重視する姿勢を反映しています。
この考え方は、アジャイル開発やXPの原則とも一致しており、固定的な規則よりも、状況に応じた柔軟な対応を重視しています。
7. 推奨書籍
詳細解説:
Fowlerは、インタビューの中で2冊の本を特に推薦しています。これらの本は、ソフトウェア開発者にとって価値ある洞察を提供するものとして紹介されています。
a) 「The Art of Agile Development」by James Shaw
この本についてFowlerは以下のように述べています：
- ソフトウェア開発の全体像を理解するのに最適な本
- エクストリームプログラミング（XP）の原則に基づいている
- 非常に実践的で、読者がすぐに適用できる内容
- 不必要な理論的な内容を避け、実用的なアドバイスに焦点を当てている
- 月曜日から職場で使えるような具体的なテクニックを提供している
Fowlerは、この本がソフトウェアプロセスとソフトウェアエンジニアリングに関する現時点で最良の書籍だと評価しています。
b) 「Make No Law」
この本は、ソフトウェア開発とは直接関係ありませんが、Fowlerは法律とソフトウェア開発の間に興味深い類似点を見出しています：
- 1960年代初頭のサリバン訴訟に関する本で、アメリカの言論の自由に関する重要な判例を扱っている
- 法律文書の作成プロセスとソフトウェア開発プロセスの類似性を示唆している
- 両者とも、複雑なシステムの中で特定の行動を規定しようとしている
- 法律は人間（非決定論的）を対象とし、ソフトウェアはコンピュータ（決定論的）を対象としているが、プロセスには類似点がある
- 憲法の改正など、複雑な「レガシーシステム」を扱う点でも類似している
Fowlerは、この本を通じて、ソフトウェア開発者が自分たちの仕事を異なる視点から見ることができると考えています。また、AIの発展に伴い、ソフトウェア開発者も非決定論的なアクターのためのプログラミングについて考える必要が出てくるかもしれないと示唆しています。
これらの推薦は、Fowlerが技術的なスキルだけでなく、広い視野と多様な知識の重要性を強調していることを示しています。ソフトウェア開発の実践的なスキルと、より広い社会的、法的な文脈の理解を組み合わせることの価値を示唆しています。