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

■ トピック

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

■ 参考リンク

• AIは計画を立て時に嘘をつく — Anthropicが言語モデルの思考回路を解明 \| XenoSpectrum
• tc39/proposal-type-annotations

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム
• SQLアンチパターン - O'Reilly Japan
• O'Reilly Japan - ルールズ・オブ・プログラミング

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム
• プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 - 秀和システム
• O'Reilly Japan - ルールズ・オブ・プログラミング

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• Interface segregation principle - Wikipedia
• Lodash
• GraphQL

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• GitHub - faker-js/faker
• Mock Service Worker - API mocking library for browser and Node.js
• Testing Library

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• テスト戦略（テストピラミッド、テストダイヤモンド）
• Mock Service Worker - API mocking library for browser and Node.js
• express

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• XUnit Test Patterns - Gerard Meszaros
• Xunit - Martin Fowler's Bliki (ja)
• テストダブル - Martin Fowler's Bliki (ja)
• Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ 参考リンク

• O'Reilly Japan - ルールズ・オブ・プログラミング

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

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

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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

■ トピック

• リスコフの置換原則だけ浮いてる？
• Javaが生まれる前に生まれた原則
• リスコフの置換原則としては意識していなかった
• 『クリーンアーキテクチャ』より「正方形・長方形問題」
• 抽象的な型で受け取ったのに具体的な型での条件分岐が発生する
• タクシー配車サービスの例
• SOLIDの中での存在感
• もっといい名前はある？
• 元になる型と派生型があればリスコフの置換原則は成り立つ
• 型として置換可能であることと、振る舞いとして置換可能であることを一致させる
• 関数の中でどうせ分岐するなら最初からシグニチャを分けたら？
• 心当たりある人は多そう
• やはり『クリーンアーキテクチャ』は読むべき

■ 参考リンク

• リスコフの置換原則 - Wikipedia
• バーバラ・リスコフ - Wikipedia
• 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」ＲｏｂｅｒｔＣ．Ｍａｒｔｉｎ - KADOKAWA

■ おたよりフォーム

https://forms.gle/RYUG7T4ctmF7Srf36

■ X（Twitter）

https://twitter.com/refactoradio

■ Bluesky

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

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