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

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック リファクタリングモードに入ってまずやること 名前を変えてみる 既存コードをいったん消して書き直してみる コメントを書き足すだけでもリファクタリング 「3つ目」が降ってくるとき 趣味と業務 知識が不確実だと備えが必要 いつでもリファクタリングはじめられるためにやっていること ディレクトリ構造をきれいにしておく 新しいメンバーからのフィードバックは大事 雑にリファクタリングしまくるためのテストとCI 「テストが書ける状態」でテストが書かれることなくない？ 息をするようにリファクタリングするには安心が必要 ■ 参考リンク #36 DRYとYAGNI① DRYとは「知識」と「表現」の原則である ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック 既存コードを触っていてリファクタリングモードに切り替わるタイミング 「なんかリファクタリングするところないかな〜」 既存のコードを掌握するためのリファクタリング レビュー基準が変化することで崩れる一貫性を見直す コードベースとの関係性とリファクタリング 変更している途中でブレーキがかかってリファクタリングに切り替わる まさしく「コードスメル」 「なんかクサい」という直感 臭ってきたときの捨てやすさ プログラマーが鍛えるべきは嗅覚 完璧なメタファー 嗅覚はタイミングのためにある セルフレビューは「臭くなかったら出せ」という暗黙のルール ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック リファクタリングモード モードの切り替わりのタイミング 耐えられなくなる閾値 「こんなつもりじゃなかったんだけどな」 どこまで行けるかぶち当たりに行く グリーンになる前にリファクタリングしてしまう悪い癖 名前を真剣に考え始めるタイミングの違い リファクタリングモードから帰ってこない チーム開発ならいったん議論してから 結局「驚き最小の原則」 書く自分と読む自分 読む自分が耐えられなくなったときに始まるリファクタリング ■ 参考リンク 驚き最小の原則 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック AngularはなぜDIを備えている？ GoogleはDIがやりたくてAngularJSを作った？ JavaScriptの世界でOOPのプラクティスを実現したかったんじゃないか 型で依存性の注入をやるためのTypeScript化 AtScriptという要件 AngularはDecoratorsが標準化されなくても困らない Angularを使いたくなる理由 Angularが与えた影響 原則を強制させるためのフレームワーク AngularはDIフレームワークである（過言？） 空気のようになっているDIP ■ 参考リンク Angular公式ドキュメント AngularはDecoratorsが標準化されなくても困らない - lacolaco inversify/InversifyJS microsoft/tsyringe NestJS ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 依存性の注入とは何か？ インスタンス作成の詳細を隠蔽したい コンストラクタに依存するインスタンスを渡していれば依存性の注入と言えるか サービスロケーターパターンとの違い DIはテストのためにあるのか？ 結局はカプセル化と隠蔽 DIもDIPを実践する手段のひとつに過ぎない ■ 参考リンク #42 カプセル化① 「秘密」と「隠蔽」 カプセル化は人形遊びで鍛える ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック SOLIDのD、依存性逆転の原則 依存性って何？逆転って何？ 依存関係とクラス図 インターフェースと実装の分離 知らないうちにやってたDIP 依存性の注入との混乱 駆け出しでDIPを学ぶべきか？ 開発がスケールするためにはDIPが必要そう 「いつまで経っても変更作業が終わりません」 カプセル化とDIP ■ 参考リンク #14 単一責任原則① 責任が単一であるってどういうこと？ 『レガシーコード改善ガイド』マイケル・C・フェザーズ | 翔泳社 #42 カプセル化① 「秘密」と「隠蔽」 カプセル化は人形遊びで鍛える ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 引数が変わりやすい関数は秘密を隠蔽できていない シグニチャがころころ変わる関数はリファクタリングに失敗している データとロジックのカプセル化のツールとしてのクラス 何を隠蔽したいのか？で何を使うかを考える 委譲の隠蔽、仲介人の除去 「デメテルの法則」にのめり込みすぎたコード データベースのJOINが透けて見えるJSON 「時には役に立つデメテルの提案」 経験を積んで変わった『リファクタリング』の読み方 ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック カプセル化との出会い 「カプセル化って何ですか？」 カプセル化とクラスベースオブジェクト指向 カプセル化とモジュール化は違う カプセル化のキモは隠蔽である 「隠蔽すべき秘密を持っているか？」 ソースコード上の「秘密」の感覚と擬人化 ミューテーション前提のカプセル化 急速に重複するロジック 続きは後編へ ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック lacolacoが最近キーボードを買った話 キーボードの交換と破壊的変更 新しいマシンを買ってもすぐに使わずマイグレーション期間を設ける okunoがトラックパッドを買った話 職場と家で腕の動きを揃えたい 使えなくなったUSBケーブルはデッドコード削除しよう 次回から『リファクタリング』の第7章「カプセル化」を読みます ■ 参考リンク DrunkDeerのキーボードを買った | Marginalia リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック バリデーションしてますか？ フォームのバリデーションとAPIのバリデーション zod, valibotで変わったバリデーションの書き方 バリデーションの種類の違い 仕様をあとから変更することの難しさ [object Object] の恐怖 クライアント側での防御的なレスポンスバリデーション スキーマと実装の一貫性をどう保証するか？ 防御的に実装しても損はしない バリデーションがあることでリファクタリングしやすくなる ■ 参考リンク Zod Valibot ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック GraphQLを使い始めたモチベーション スキーマ駆動開発 スキーマ中心の分業はだいぶメジャーになった 手書きのスキーマがメンテナンスしやすいかどうか Excelの「電文仕様書」 「必須」パラメータの定義の悩み スキーマ記述言語としてGraphQLを気に入っている話 zod, valibot バリデータを書くとスキーマが手に入る フロントエンドでもバックエンドでもないところでスキーマを書けるのが重要 結局TypeScriptの型がスキーマになっている ■ 参考リンク GraphQL OpenAPI Initiative Zod Valibot ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック HTTP通信どうしてる？ APIエンドポイントのURL設計 APIのバージョニングの是非 APIの破壊的変更をどう避ける？ v3が生まれたらおしまい OSSのやりかたは参考になる API仕様の変更のしやすさ URLは使う登場人物が多いから厄介 ■ 参考リンク O'Reilly Japan - 進化的アーキテクチャ ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック YAGNIってDRYと対立する原則なのか？ YAGNIとどこで出会った？ 抽象化を身につけ始めた初心者にYAGNIが刺さる DRYに従うことこそがYAGNIの原則を実現するのでは？ 「何が必要か」を判断するのは知識 まだ不確実な知識を取り込んだDRYはYAGNIに反する 知識が間違ってるかどうかは話してみないとわからない 原則を守ってコードを書くのは他人と円滑に仕事をするため 将来を心配しすぎたコード DRYを守った結果YAGNIに反するとしたら、知識の不足か、心配性かではないか フレームワークにどれだけ依存して実装するか DRYやYAGNIの失敗談などコメントお待ちしております ■ 参考リンク Google Testing Blog: Don't DRY Your Code Prematurely YAGNI - Wikipedia プリンシプル オブ プログラミング 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック Google Testing Blogの気になる記事 早すぎる抽象化によるDRYの危険性 DRYに対置されるのはYAGNIなのか？ DRY原則はいいコードを導く？ DRYは悪者なのか？ 「すべての知識は、システム内で単一の、明確な、信頼できる表現を持たなければならない」 Google Testing Blogで否定されたDRY原則はそもそも原典でも否定されている ドキュメントの二重化 異なる知識から同じ表現が生まれることはありえる DRYに反してるかどうかは「知識」とその「表現」 「開発者間の二重化」 ライブラリアン 『達人プログラマー』第二版を読んでDRYの誤解を解こう ■ 参考リンク Google Testing Blog: Don't DRY Your Code Prematurely Don't repeat yourself - Wikipedia 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック Publickeyに掲載された記事の紹介 命名的問題と構造的問題 読みやすいと思ったコードのほうが読解を間違っていた 間違った名前を間違ったまま受け取ってしまっている 「読めた気になれる」コードは間違いやすい 確かな名前を頼りに難しいコードを読むことはできる 「コードの書き手との信頼関係」 防御的に読むモードに切り替わる わからないほうが誤解されるよりマシ ぜひ元の記事を読んでみてください ■ 参考リンク 技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック Diffの将来を妄想する GitHubは完成形なのか？ Diffは結局パッチファイル 差分が取れるものはすべてDiffにしてしまうのでは？ Yet Another GitHubを想像する Gitの次はどうやったら生まれるか？ プログラミングが音声入力になったら？ 再現性がなければバージョン管理をしても意味がなさそう 結局ロールバックしたい GitHubに依存しすぎた開発にも反省するところがある 特にオチのない話でした ■ 参考リンク Git トランクベース開発 | Atlassian ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック われわれはどのようにDiffを作っているのか？ laco: ブランチのDiffをいったんすべて並べてまとめ直す 注目すべきコミットをわかりやすくする okuno: 1コミットにすべて詰めこんで検証したうえで消して別ブランチで書き直す リリース戦略とプルリクエストの作り方 仮コミットと仮ブランチ 書くべきコミットはなく、残すべきコミットを考える ログに残されるコミットの選抜試験 これもまたテスト駆動開発なのでは？ 読みにくいプルリクエストはRed-Greenで終わってしまっている まずチケットがあり、タイトルとブランチ名は自動的に決まる "Works fine" を反面教師として学ぶ OSSのチェンジログは参考になる ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック Diffのデザインに気をつけている話 GitHubのプルリクエストで見るDiff OSSのチェンジログからみるDiff なぜプルリクエストの単位でDiffを見るのか Diffから意図を取り出すのは難しい 履き違えられたボーイスカウトルール 関係ないファイルの「ついで直し」はボーイスカウトではない リバートされることを考えて変更差分を作る 「リリースノートを作る気持ちになってごらん」 他の人のためのテキスト・ドキュメントを作っているという意識 Squash vs Merge コミットログの作り方にもこだわりがある（次回へ続く） ■ 参考リンク ボーイスカウト・ルール | プログラマが知るべき97のこと ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック コロケーション（co-location）って何？ テストコードのファイルをどこに置くか 同じファイルにテストを書くところ（In-source Testing）まで来た テストとテスト対象は近ければ近いほどいい？ 『レガシーコード改善ガイド』におけるコロケーションの話 デプロイのためのファイル配置 glob-ability高い命名規則がが定まればコロケーションができる OSSのコードにはいまでもtestディレクトリをよく見る コロケーションの実現にはツールによる支援が必須である Obj-Cのヘッダファイルとメインファイルはコロケーションか？ 分けて置く選択肢があるにもかかわらず寄せようというのがコロケーション 書く人が違った時代はディレクトリを分けておくインセンティブがあった テストを書く開発者が増えたことでコロケーションの需要が高まった？ 同じ人が作業するファイルがまとまっていることに意味がある これもまた「コンウェイの法則」 なぜE2Eテストのファイルはコロケーションされていないのか？ モノレポも広義のコロケーションかもしれない マクロのコロケーション・ミクロのコロケーション 実装とドキュメントのコロケーション そのディレクトリだけ見てればいい状態 ファイルが多いよりディレクトリが多いほうが脳が楽そう ■ 参考リンク Colocation In-Source Testing | Guide | Vitest レガシーコード改善ガイド｜翔泳社の本 Conway's law - Wikipedia ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック おたよりをいただきました ファイル・ディレクトリ周りで参考にしているルール フレームワークの基本的なディレクトリ構造 ディレクトリベースドルーティング ファイルと変数の命名規則は分けたい 設定より規約、の振り子 考えることを減らすというトレンド ファイル名についてのコントロールを持っていたい globbableなファイルの命名 `foo.spec.js` 形式（第二拡張子？） マジック（マジカル）ナンバー7±2 ファイル数とディレクトリ階層のバランス コロケーションについては次回へ ■ 参考リンク プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ - 秀和システム ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。