■ トピック

• リファクタリングの未来
• AIコーディングエージェントは脅威ではなかった？
• 「リファクタリングが不要になる未来」
• 「長すぎる関数」は「長すぎる要件定義」に変わるだけ
• 大元のプロンプトが新たな「ソフトウェア」になる
• ソフトウェアがある限り、リファクタリングは消えない
• ご挨拶
• 今後の予定
• 年明けの生放送、チャンネル登録、Twitterフォローでお見逃しなく!

■ 参考リンク

• ep100: 【ゲスト:和田卓人さん】あなたのリファクタリングはどこから？「三度の飯よりリファクタリング」を語る
• ep103: 開放閉鎖原則① SOLIDのO 「拡張に開き、修正に閉じる」って何？
• ep104: 開放閉鎖原則② リファクタリングの究極の目的 ―開放閉鎖原則とTDD―
• ep105: 開放閉鎖原則③ すべてがOになる

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• シーズン1最終回直前！2年間の総括
• okunokentaroのCodeGrid連載
• お便り・コメント紹介
• 2年間のポッドキャスト統計
• 人気エピソードランキング
• lacolacoが選ぶベスト回
• okunokentaroが選ぶ名言
• ep016「右手にSRP、左手にDRY」を振り返る
• 2年間の学び: OCPと命名がリファクタリングの核
• 次回予告: リファクタリングはどこへ向かうか

■ 参考リンク

• CodeGrid連載「プログラミングにおける名付けの考え方」
• ep001: 名前にどこまで意味を込めるか
• ep008: 長すぎる関数② 長くなる前にテストを書こう
• ep014: 単一責任原則① 責任が単一であるってどういうこと？
• ep016: 単一責任原則③ 右手にSRP、左手にDRY
• ep022: コメント③ 書くべきコメントよりも残すべきコメントについて考える
• ep034: Diff③ 「Gitの次」ってどうなる？
• ep094: 見積もりと経験/足し算のコードと引き算のコード
• ep100: 【ゲスト:和田卓人さん】あなたのリファクタリングはどこから？「三度の飯よりリファクタリング」を語る
• ep103: 開放閉鎖原則① SOLIDのO 「拡張に開き、修正に閉じる」って何？
• ep104: 開放閉鎖原則② リファクタリングの究極の目的 ―開放閉鎖原則とTDD―
• ep105: 開放閉鎖原則③ すべてがOになる

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• 「すべてがOになる」
• SOLID原則の中で「O」だけレイヤーが違う
• OCPはクラス設計だけでなくソフトウェア全体の原則
• ソフトウェアの持続的な成長を可能にするOCP
• 「機能追加はコードの追加だけで済む」という理想状態
• 仕様変更コストの「連続性」
• 「足すだけ」が「足すだけ」で済まないのはOCP違反のサイン
• 機能追加で感じる「痛み」
• レビューの辛さも「痛み」
• デザインパターンのほとんどはOCPを満たすためにある
• AI時代における開発の「痛み」の感じ方

■ 参考リンク

• デザインパターンとOpen-Closed Principle

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• OCPとTDDの深い関係性
• 「開放閉鎖原則は徐々に満たされる」
• YAGNI原則との繋がり「どこまで拡張性を持つべきか」
• TDDのサイクルで感じる「痛み」が設計改善のサイン
• 今日のための設計
• コードの「痛み」はOCP違反のシグナル
• リファクタリングの究極の目的はOCPを満たすこと？
• 息をするようにOCPに近づける
• YAGNIの指針「目の前の痛み」だけに対処する
• YAGNIを保ちつつ拡張性を高める方法
• LLM/AIはコードの「痛み」を感じない？
• OCPの理想にTDDで一歩ずつ近づく

■ 参考リンク

• 『テスト駆動開発』Kent Beck 著, 和田卓人 訳
• ep100: 【ゲスト:和田卓人さん】あなたのリファクタリングはどこから？「三度の飯よりリファクタリング」を語る
• ep101: 【ゲスト:和田卓人さん②】令和のリファクタリング、どう学ぶ？ LLMと本それぞれの役割
• ep036: DRYとYAGNI① DRYとは「知識」と「表現」の原則である
• ep037: DRYとYAGNI② DRYとYAGNIの両立 知識不足と心配性

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• SOLID原則最後のテーマ「O」
• なぜ「O」を最後に残したのか？
• 「拡張に対して開き、修正に対して閉じる」
• 『Clean Architecture』におけるOCPの重要性
• なぜ税率変更で既存コードを修正してはいけないのか？
• 「修正に対して閉じる」とはどういうことか？
• 他のモジュールから依存されているコードは変更しない
• 「リファクタリング」ができる状態は「閉じている」
• 「拡張に対して開く」とはどういうことか？
• Gitのdiffが「追加だけ」で済むのが理想
• 実務例: POSレジ連携における「ストラテジーパターン」の活用
• OCPは他のSOLID原則の根本である
• 安定しつつ将来の仕様変更に柔軟であるという矛盾した理想論

■ 参考リンク

• 『オブジェクト指向入門 第2版 原則・コンセプト』
• 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』
• トレタ社での事例 POSレジ連携アーキテクチャの解説資料

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• Agentic Codingと言語・カルチャーの関係
• 現場のカルチャーがAI活用に与える影響
• ドキュメント文化とAIの親和性
• オンボーディングとAI協業の類似性
• 「毎日記憶喪失の新人が来る」AIとの付き合い方
• プロンプトを書く作業は苦痛なのか
• 日本語 vs 英語、プロンプトの言語選択
• コードファーストとドキュメントファースト
• どうコードスメルを感じるか？
• AIによるテスト自動生成の限界
• Few-shot学習の重要性
• Agentic Codingは「幻滅期」に入ったか
• AIはプログラミングを続けたい人にとっての脅威か
• バイブコーディングは「非エンジニアのための革命」
• プログラミングの裾野を広げるAIの可能性
• バイブコードクリーナップスペシャリストという新職種

■ 参考リンク

• 和田卓人さん X (Twitter)
• Kiro

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• 令和時代のリファクタリングの学び方
• AIが学習の主要な入り口になる時代
• 若手エンジニアのAI活用と学習パス
• AIの強み「心理的安全性」と「即時フィードバック」
• AIが専門用語への到達を助ける
• 保守性という概念への出会い方
• AIの弱点「質問しないと答えてくれない」
• 本の役割「偶発的な出会いを提供する」
• LLMと背景を共有するための古典学習
• 人名でコンテキストを絞る技法
• LLMの知識量と設計判断のギャップ
• プロンプトは「引き算」の作業
• AIエージェント流行後のTDD本の売上増
• 技術書の火を絶やさないために
• 図書館活用のすすめ
• おすすめ古典
• ケント・ベック『Tidy First?』解説
• 「リファクタリング」という言葉の意味の変化
• 「Tidy（片付け）」という新しい概念
• 構造変更と振る舞い変更の分離
• レビューコストの最適化

■ 参考リンク

• 和田卓人さん X (Twitter)
• 『プログラミング作法』 (アスキードワンゴ)
• 『プリンシプル オブ プログラミング』 (秀和システム)
• 『Tidy First?』 (オライリー・ジャパン)

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• ゲスト紹介: 和田卓人さん（t_wadaさん）
• 和田さんの現在の活動
• あなたのリファクタリングはどこから？
• 1999年当時のソフトウェア開発環境
• XMLバブルとキャリア初期の苦悩
• プログラマーとしての自信とプライドの喪失
• エクストリームプログラミングとの出会い
• Junitとの出会い「テストをコードで書いていい」
• リファクタリングがプログラマーの誇りを取り戻した
• 奥野とリファクタリング
• 図書館での独学とオブジェクト指向の学習
• デザインパターンとテストの実践
• lacolacoとリファクタリング
• オープンソースと「人に見せられるコード」への欲
• 個人開発でのテストとデザインパターンの実験
• 3人共通のオブジェクト指向言語との関わり
• スモールトークからJavaへの技術移植の歴史
• 次回予告: これからの時代のリファクタリングの学び方

■ 参考リンク

• 和田卓人さん X (Twitter)
• リファクタリング（第2版） (オーム社)
• エクストリームプログラミング (オーム社)
• 達人プログラマー（第2版） (オーム社)

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• コード削除の難しさについて
• 削除操作は簡単だが影響範囲の見積もりが困難
• 「消し残し」はエラーにならず発見しにくい
• 「消しすぎ」はテストカバレッジ外で防げない
• 存在しないことを証明する難しさ
• 外部コンソールの環境変数削除の困難さ
• デッドコードをレッドな状態にするアプローチ
• テスト駆動開発のエッセンス「まずレッドから」
• AIを信頼するとはどういうことか
• 信頼と不信はイコールではない
• 信頼の要素「コミットメント」「力量」「善意」
• AIに「意図」はあるのか
• 利害関係による信頼の脆弱性
• 感情の信頼と恩義
• 制度的な信頼と役割
• AIへの信頼はベンダーの意図に依存する
• 次回第100回記念ゲスト回！

■ 参考リンク

• 信頼と不信の哲学入門 (岩波新書)
• 信頼と裏切りの哲学 (慶應義塾大学出版会)

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。

■ トピック

• AIエージェント向けのドキュメント、どうメンテする?
• 人間に見せたいドキュメントとAIに見せたいドキュメント
• コンテキストサイズを抑えたい
• 用語集的なドキュメント
• AI特有の読み方のバイアス
• タグによる構造化
• AIにタスク実行ではなくスクリプト作成を指示する
• データ量というコンテキストがAIの提案を変える
• プロンプトよりもコンテキストが重要

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

https://bsky.app/profile/refactoradio.com

ハッシュタグは #リファラジ です。