リファクタリングとともに生きるラジオ

■ トピック TSKaigi 2026でテスト駆動開発の話してきた コードレビュー完全にやらなくなった 『ソフトウェア設計と結合バランス』はいいぞ ■ 参考リンク TSKaigi 2026 登壇『いつテストを書くか？』: https://blog.lacolaco.net/posts/tskaigi-2026-deck フロントエンドカンファレンス福岡 2026: https://frontend-conf.fukuoka.jp/2026/ 『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』: https://b...

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

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

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

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

■ トピック SOLID原則最後のテーマ「O」 なぜ「O」を最後に残したのか？ 「拡張に対して開き、修正に対して閉じる」 『Clean Architecture』におけるOCPの重要性 なぜ税率変更で既存コードを修正してはいけないのか？ 「修正に対して閉じる」とはどういうことか？ 他のモジュールから依存されているコードは変更しない 「リファクタリング」ができる状態は「閉じている」 「拡張に対して開く」とはどういうことか？ Gitのdiffが「...

■ トピック Agentic Codingと言語・カルチャーの関係 現場のカルチャーがAI活用に与える影響 ドキュメント文化とAIの親和性 オンボーディングとAI協業の類似性 「毎日記憶喪失の新人が来る」AIとの付き合い方 プロンプトを書く作業は苦痛なのか 日本語 vs 英語、プロンプトの言語選択 コードファーストとドキュメントファースト どうコードスメルを感じるか？ AIによるテスト自動生成の限界 Few-shot学習の重要性 Agentic Codingは...

■ トピック 令和時代のリファクタリングの学び方 AIが学習の主要な入り口になる時代 若手エンジニアのAI活用と学習パス AIの強み「心理的安全性」と「即時フィードバック」 AIが専門用語への到達を助ける 保守性という概念への出会い方 AIの弱点「質問しないと答えてくれない」 本の役割「偶発的な出会いを提供する」 LLMと背景を共有するための古典学習 人名でコンテキストを絞る技法 LLMの知識量と設計判断のギャップ プロンプト...

■ トピック ゲスト紹介: 和田卓人さん（t_wadaさん） 和田さんの現在の活動 あなたのリファクタリングはどこから？ 1999年当時のソフトウェア開発環境 XMLバブルとキャリア初期の苦悩 プログラマーとしての自信とプライドの喪失 エクストリームプログラミングとの出会い Junitとの出会い「テストをコードで書いていい」 リファクタリングがプログラマーの誇りを取り戻した 奥野とリファクタリング 図書館での独学とオブジェクト指...

■ トピック コード削除の難しさについて 削除操作は簡単だが影響範囲の見積もりが困難 「消し残し」はエラーにならず発見しにくい 「消しすぎ」はテストカバレッジ外で防げない 存在しないことを証明する難しさ 外部コンソールの環境変数削除の困難さ デッドコードをレッドな状態にするアプローチ テスト駆動開発のエッセンス「まずレッドから」 AIを信頼するとはどういうことか 信頼と不信はイコールではない 信頼の要素「コミッ...

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

■ トピック AIの台頭とプログラミング言語との付き合い方 新しいユースケースと言語の細分化 AIがシンタックスを補完する時代 アーキテクチャとその背景にある哲学 制約の強い言語の方がAIにとって安全 AIが生成する読みにくいコードという新たなカオス AIファースト言語設計の可能性 AngularチームのGemini活用事例 フロントエンドとバックエンドのTypeScript統一の実質 言語統一は幻想、統一すべきは哲学 「言語の地図」 ■ 参考...

■ トピック 言語統一は幻想か？ プラットフォームによる言語制約の現実(モバイルなど) フルスタックTypeScriptは本当に「同じ言語」か？ 統一を目指すとかえって生まれる「方言化」 真の統一に必要な「スキーマ」と「メンタルモデル」 言語統一の目的「コンテキストスイッチ削減」は達成できるか サーバーとクライアントのコード共通化が招く予期せぬエラー 次回はAIコーディング時代の言語選定へ ■ 参考リンク 1つの言語 ■ おたよ...

■ トピック マーティン・ファウラーさんのブログ記事「OneLanguage」 1995年は多くのプログラミング言語が生まれた当たり年 2007年頃の言語事情 組織、システム、個人のレベル なぜ大企業は独自言語を作りたがるのか Webフロントエンドにおける言語統一の限界と WebAssemblyの可能性 個人のキャリアと複数言語習得 言語を1つに統一するのは幻想か？ ■ 参考リンク 1つの言語 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf3...

■ トピック 新卒研修での見積もりのズレ 「不確実性コーン」 プログラマーが遅延する2つの要因 要件の「登場人物」から危険度を察知する嗅覚 シニアのコードは「引き算」、若手のコードは「足し算」 0行の時点で匂いを感じる熟練者 AI時代でも「経験したいことは自分でやるしかない」 人間は「経験担当」、AIは「知識担当」 ■ 参考リンク 同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？ 不確実性コーン ■ お...

■ トピック 「長すぎる関数」のリバイバル AIが生成する長い関数とコメント AIにとっても「長すぎる関数」はスメルである AIは既存のコードスメルを強化する コードスメル「仲介人（ミドルマン）」とAI AIはオブジェクト指向的な設計が苦手 理想と現状のギャップを埋める試行錯誤 AI時代でもリファクタリングの哲学は変わらない エージェンティックコーディングによって「新しい匂い」が生まれるか ■ 参考リンク #7 長すぎる関数①...

■ トピック 過去の「重複コード」回のリバイバル AIコーディングの流行により何か変わったか？ AIによる意味的な重複コード検出の課題 重複コードに気づく人間の「嗅覚」の重要性 「名前をつけようと思い至るスキル」 AIは「新入社員」でありドキュメントが重要 ソースコードが文字列である限り「スメル」は変わらない ■ 参考リンク #4 重複コード① 似てるのに微妙に違う「重複もどき」が一番怖い リファクタリング（第2版） 既存...

■ トピック ポッドキャストの居酒屋収録の難しさ 店内BGM問題 日傘を買った ワイヤレスイヤホンの使い分け 「エンジニア35歳定年説」 エンジニアの健康維持とヘルストラッカー 「ヘルストラッカーは自分の体に対するリンター」 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。

■ トピック 今回はおたより・コメント紹介 Voicyよりちゃぶ台さんのコメント 「1万行のC言語ファイル、1000行の関数、三重の無限ループ」 部屋やPCファイルの整理整頓はできてる？ Macのホームディレクトリ以下のプロジェクトフォルダのパス 懐かしの回へのコメント RaycastとClaude Code 定期的に「達人度合い」を測ろう ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradi...

■ トピック 重大告知 リファラジは2025年末でシーズン1終了します 完結に向けて、リスナーへのお便りやネタは早めに送ってください やり残しているテーマ SOLIDのOの回 今後5年10年のリファクタリング リファクタリングとは一体何であったのか、そして今後何であるのか 名前の付け方って変わった？ すでに陳腐化してしまった過去回 毎週更新のポッドキャストって結構大変 ネタ出しをぜひご協力ください！ ■ おたよりフォーム https...

■ トピック AIを使った新規開発 新しい技術への対応 AIの「記憶喪失」問題 生前贈与型アプローチ fidxの開発 OSS公開の容易化と心理的ハードルの低下 AI時代のセルフコードレビュー v1.0.0リリースの覚悟 ■ 参考リンク Claude Code GitHub - crescware/fidx GitHub - yoshiko-pg/difit ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profi...

■ トピック 既存コードベースでAIをどう使う？ LLMに任せる作業の種類 README.mdを書かせる コードベースの「地層」問題 リファクタリングの新たな目的 ■ 参考リンク Claude Code ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。

■ トピック 桜井政博のゲーム作るには 「お客さんに説明できるの？」 ヘルプメッセージへのこだわり 「監修あれこれ」 名前の回「ファイル名は合理的に」 「仕事の姿勢」シリーズは新卒におすすめ ■ 参考リンク 桜井政博のゲーム作るには - YouTube #73 銚子ドライブ編③ どうする？新人エンジニア育成 lacolacoイチオシ回 - お客さんに説明できるの？ 【仕事の姿勢】 メニューにヘルプを 【UI】 okunoイチオシ回 - 監修あれこ...

■ トピック コードレビューする側で考えていること、やっていること 自動化できないルールを守らせるのは無理 LLMを使ったルールの非決定論的自動化の可能性 AIによってルールがねじ曲がった例 LLMのためのコード内コメント コードレビューのWhyに立ち返る ■ 参考リンク 秀和システム『Looks Good To Me』 #20 コメント① コメントを「ちゃんと書く」って何？ #74 リンター/フォーマッター① Prettierは脳にインストールされている ■...

■ トピック プルリクエストを出す側の話 誰がレビュアーか念頭に置いてコードを書くか レビュアーのコメントをドキュメントの材料にする 「リファクタリング定例」 セルフレビューの重要性 diffの出方にこだわる美意識 ■ 参考リンク 秀和システム『Looks Good To Me』 #32 Diff① 「ついで直し」はボーイスカウトルールではない ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refact...