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

■ トピック

• データ基盤とリファクタリング
• やはりレビューがボトルネックになってしまう話

■ 参考リンク

■ トピック

• Vibe Refactoringの実践
• シン・ボーイスカウトルール
• 「5行ルール」をやってみた
• ADRを活用したAIコードレビュー

■ 参考リンク

■ トピック

• AIエージェント暴走の夏
• MicroVMで開発環境を隔離する
• おたより「フロントエンドのテスト技法」
• 画像回帰テストの限界と「開くためのテスト」
• 気になる記事・AIと品質保証

■ 参考リンク

■ トピック

• 書籍紹介『実践で学ぶコード改善の極意』
• 書籍紹介『我ら、プログラマー』

■ 参考リンク

■ トピック

• TSKaigi 2026でテスト駆動開発の話してきた
• コードレビュー完全にやらなくなった
• 『ソフトウェア設計と結合バランス』はいいぞ

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ おたよりフォーム

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

• 新卒研修での見積もりのズレ
• 「不確実性コーン」
• プログラマーが遅延する2つの要因
• 要件の「登場人物」から危険度を察知する嗅覚
• シニアのコードは「引き算」、若手のコードは「足し算」
• 0行の時点で匂いを感じる熟練者
• AI時代でも「経験したいことは自分でやるしかない」
• 人間は「経験担当」、AIは「知識担当」

■ 参考リンク

■ トピック

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

■ 参考リンク

■ トピック

• 過去の「重複コード」回のリバイバル
• AIコーディングの流行により何か変わったか？
• AIによる意味的な重複コード検出の課題
• 重複コードに気づく人間の「嗅覚」の重要性
• 「名前をつけようと思い至るスキル」
• AIは「新入社員」でありドキュメントが重要
• ソースコードが文字列である限り「スメル」は変わらない

■ 参考リンク

■ トピック

• ポッドキャストの居酒屋収録の難しさ
• 店内BGM問題
• 日傘を買った
• ワイヤレスイヤホンの使い分け
• 「エンジニア35歳定年説」
• エンジニアの健康維持とヘルストラッカー
• 「ヘルストラッカーは自分の体に対するリンター」

■ おたよりフォーム

■ トピック

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

■ おたよりフォーム

■ トピック

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

■ おたよりフォーム

■ トピック

• AIを使った新規開発
• 新しい技術への対応
• AIの「記憶喪失」問題
• 生前贈与型アプローチ
• fidxの開発
• OSS公開の容易化と心理的ハードルの低下
• AI時代のセルフコードレビュー
• v1.0.0リリースの覚悟

■ 参考リンク

■ トピック

• 既存コードベースでAIをどう使う？
• LLMに任せる作業の種類
• README.mdを書かせる
• コードベースの「地層」問題
• リファクタリングの新たな目的

■ 参考リンク

■ トピック

• 桜井政博のゲーム作るには
• 「お客さんに説明できるの？」
• ヘルプメッセージへのこだわり
• 「監修あれこれ」
• 名前の回「ファイル名は合理的に」
• 「仕事の姿勢」シリーズは新卒におすすめ

■ 参考リンク

■ トピック

• コードレビューする側で考えていること、やっていること
• 自動化できないルールを守らせるのは無理
• LLMを使ったルールの非決定論的自動化の可能性
• AIによってルールがねじ曲がった例
• LLMのためのコード内コメント
• コードレビューのWhyに立ち返る

■ 参考リンク

■ トピック

• プルリクエストを出す側の話
• 誰がレビュアーか念頭に置いてコードを書くか
• レビュアーのコメントをドキュメントの材料にする
• 「リファクタリング定例」
• セルフレビューの重要性
• diffの出方にこだわる美意識

■ 参考リンク

■ トピック

• 秀和システムから発売されたコードレビュー本『Looks Good To Me』の紹介
• コードレビュー本ブーム
• セルフレビューの責務
• バグの発見をコードレビューの目標に含めるべきか
• AIコードレビューの限界
• 次回からコードレビューの現場編へ

■ 参考リンク

■ トピック

• vol.77のV言語に続き、新しい言語を学ぼうシリーズ
• okunoがMoonbitを学んでみた
• WebAssemblyに特化した言語
• 構文の特徴
• エラーハンドリングの癖が強い
• 嬉しい検査例外
• 入門してみての感想
• 「年に1つ言語を学ぶ」ことの重要性
• 達人への道は続く...

■ 参考リンク

■ トピック

• lacolaco のTSKaigi 2025登壇からSignalについて掘り下げる
• Signalとは何か？
• なぜ今Signalが盛り上がっているのか？
• Qtに遡るSignalの歴史
• Signalを標準化する意味とは？
• いろいろやっておくと点と点がつながる

■ 参考リンク

■ トピック

• TSKaigi 2025で登壇してきた話
• lacolacoの登壇内容
• TSKaigi会場で出会ったリファラジリスナー
• 今年のTSKaigiの感想
• 最近のリファラジの数字
• ハッシュタグ投稿よろしくお願いします
• 次回はlacolacoの発表内容掘り下げ

■ 参考リンク

■ トピック

• 達人プログラマーの「シェル遊び」
• IDEに頼るな
• 使っているシェル
• Ghosttyを試してiTerm2に戻った話
• 自分の道具箱を磨け
• プログラミングスキルとタイピング速度
• キーボードショートカットの重要性
• 「今何した？」
• Raycastへの乗り換え
• 1年に1回ツールを変えよう

■ 参考リンク

■ トピック

• 『達人プログラマー』におけるプレーンテキストの威力
• プレーンテキストとは何か？
• Unix哲学とプレーンテキスト
• LLM（大規模言語モデル）の登場とプレーンテキスト
• データ形式の選択：Excel, WordよりCSV, Markdown
• 奥野のブログ記事管理方法
• データロックインからの解放
• プレーンテキストへの揺り戻しとObsidian

■ 参考リンク

■ トピック

• 達人プログラマーへの道
• V言語の概要と出自
• あなたがもしGOを知ってるならもうVの8割は知ってます
• printlnのおもてなし
• dump 機能がすごい
• デフォルトでイミュータブルな変数
• Result型・Option型の第一級サポート
• V言語の嬉しさ
• V言語のつらさ
• 新しい言語を学んで気づくいつもの言語のありがたさ
• ※ vlang/setup-v は後日ちゃんと動かせました
• コントリビューションチャンスがいっぱいありそう
• ここから2回、達人シリーズが続きます

■ 参考リンク

■ トピック

• okunoがBiomeを推す回
• Biomeとは？
• とにかく高速
• Biome 2.0でプラグイン対応の予定
• ASTをクエリする言語「GritQL」
• デフォルト設定に注意？
• 試してみよう

■ 参考リンク

■ トピック

• リンターの設定どうしてる？
• 05:08 個人開発とチーム開発でのルール設定の違い
• リンターとCIの遅延
• 自作リンターで高速化
• 「あ、これじゃ俺も自作できんじゃないと思って」
• ASTを触ることは怖くない

■ 参考リンク

■ トピック

• フォーマッターが普及してなかった時代
• JavaScriptにおけるフォーマット・リンターの歴史
• JSLintからJSHint、ESLintへ
• 強い思想とカスタマイズ性
• Prettier普及前の思い出
• 個人開発とフォーマット・リント
• AI生成コードとフォーマット・リント

■ 参考リンク

■ トピック

• 新卒・新人エンジニアは何を身につけるべきか
• トレーニング機会の減少と高度化
• 「桜井政博のゲーム作るには」全部見ろ
• ワークショップ「リモートドローイング」
• 文章力・チャット作法は教わる機会が少ない
• 専門知識・共通言語（語彙）の重要性
• やっぱりレッド・グリーン・リファクタリング
• ジオゲッサーも研修になりそう

■ 参考リンク

■ トピック

• マネジメントの話
• リファクタリング観点のマネジメント
• マネージャーとしてのlacolaco
• 技術顧問としてのokuno
• 「噛み合い」と「持ち味」
• SREにおけるリファクタリングとは？
• 結局レッド・グリーン・リファクタリング
• 銚子に到着

■ おたよりフォーム

■ トピック

• オープニング
• 物理的な構造物とリファクタリング
• 生成AIは「ガチャ」か？
• AIコーディング支援と音声入力
• 生でJavaScriptを書く機会
• リファクタリング前提言語としてのTypeScript
• トランスパイルと型チェックの分離
• 次回に続く...

■ 参考リンク

■ トピック

• Chapter6 想定外の事態をなくす
• nullの話みんな好き
• 10年経っても変わらない
• 「値なし」についてどう考えてる？
• プログラミング言語ごとに異なる「値なし」の扱い
• undefined vs null
• 結果なしをどうする問題（NullObjectパターン）
• Nullableを受け取るところ・受け取らないところ
• 「想定外の事態をなくす」
• いかにユニットテストを短く書くか
• より少ないユニットテストでカバレッジを確保できるようにしたい
• 静的な検査と動的なテスト、契約のバランス
• 方法はユニットテストだけではない
• サンプルコードは架空の言語
• 『ルールズ・オブ・プログラミング』との共通点
• やっぱり新人に教えたいことは共通している
• 著者の思想が出ている現場のドキュメント
• 『クリーンアーキテクチャ』との違い

■ 参考リンク

■ トピック

• 『Good Code, Bad Code』の紹介
• 理論・実践・ユニットテスト
• 今回は第一部をメインに
• 『プリンシプル オブ プログラミング』とよく似た対照読者層
• 「正しく動作し続ける」ことへの思想
• 新人の教育で苦労してる姿が思い浮かぶ
• 例えが多いし的を射ていて上手い
• 「契約プログラミング」が第3章に出てくるのに驚いた
• 『ルールズ・オブ・プログラミング』でも「表明」について書かれていた
• 契約プログラミングは生成AIも読み取ってくれる
• 明確な契約は人間にとってもAIにとっても役に立つ
• 普遍性がありつつ、時代と噛み合ってる気がする本
• 次回はokunoのおもしろかった部分を紹介

■ 参考リンク

■ トピック

• アンクルボブのISP原則
• ISPのこと意識してる？
• 依存性逆転原則とごっちゃになりやすい
• SQLを例に考える
• 求めていないインターフェースにまで依存してしまうことを避ける原則
• lodashのサブパッケージはISPに従っている？
• いらないものに依存すると、不要なリスクやコストを抱えることになる
• 原則として認識してなくても、いろんなものに埋め込まれている
• GraphQLはクエリごとにインターフェースが分離される
• フェイクつくる君（第67回参照）
• ISPへの反論としてのカプセル化
• 結局は変更頻度？
• 分離したインターフェースに名前がつけられるかどうか
• 一個のモデルとしてインターフェースを命名するときにはISPが意識されている
• SRPとISPは矛盾する？
• いろんなプラクティスの背景にISPがある

■ 参考リンク

■ トピック

• lacolacoとテストダブル
• フェイクオブジェクトのファクトリ関数を作る
• テストケースごとに依存するパラメータをすべて明示する
• どのテストが何に依存しているのかをはっきりさせたい
• HTTPクライアントと差し替え・スパイのしやすさ
• そもそもテストでHTTP通信を発生させるかどうか
• 本物を使いたい気持ちとツール依存度とのせめぎあい
• HTTPレスポンスが欲しいのか、データが欲しいのか
• ユニットテストを書き続けられる状態を保ちたい
• テストフレームワークの柔軟さに甘やかされる
• ikuma-tさんおたよりありがとうございました

■ 参考リンク

■ トピック

• okunoとテストダブル
• 時間が経つと複雑なテストが増える
• テストコードとDRY
• モック作る派
• 「神」はひとつに保つ
• expressとmswに二重管理された神レスポンス
• フィールドごとの意図の違いとコピペ事故のリスク
• アプリが大きくなって、モジュールが大きいままならテストもつらくなる
• テストを直接小さくしようとするより、モジュールを小さくしていく
• 次回はlacolacoとテストダブル

■ 参考リンク

■ トピック

• ikuma-tさんからのおたより
• テストフィクスチャってなんだっけ？
• フィクスチャはなにかの代替物というわけではない
• テストダブルの種類
• xUnitというフレームワークの系譜
• なんでも「モック」と呼びがち
• 『Good Code, Bad Code』のテストダブル解説が詳しい
• 次回からは神レスポンス、神モックとの戦いについて

■ 参考リンク

■ トピック

• しゅうさんからのおたより
• リファクタリングとビジネスの折り合い
• 「リファクタリングをねじこむの大変」問題
• リファクタリングだけをやったとして、その効果実感はいつ得られるのか？
• リファクタリングをする前に完成することはない
• リファクタリングしないと恥ずかしくてコードレビューに出せない
• Good First Issueとしてのリファクタリング
• 泣きそうなトピックなら押し通す
• リファクタリングのスピード
• リファクタリングは練習可能
• 脳内リファクタリングでだいたい完成させておく
• すばやいリファクタリングの実績が次の説得を楽にする
• 割れ窓理論とAI
• AIは割れ窓も模倣してくる
• AIも新人扱いしたほうがよさそう
• 脳内リファクタリングはジャンキーですか？

■ 参考リンク

■ トピック

• ヒホさんからのおたより
• クラスを使ったリファクタリングの使いどころについて
• クラス構文を使ってないだけでクラスっぽいものを自作しているコード
• 何をどうカプセル化したいのか
• 継承を抜きにしてもクラスは便利
• グリッド状メニューの実装
• フレームワークの仕組みとの噛み合わせ
• そのリファクタリングで何を解決したいのか？
• クラスという選択肢を完全に捨てるのはもったいない

■ おたよりフォーム