■ トピック Spotify 累計10000再生突破！ リファラジリスナーの規模 『ルールズ・オブ・プログラミング』回への反響 TSKaigi会場でリスナーから声をかけられた話 みんなのリファクタリングの話も聞きたい 隅田川.dev vol.5 の告知 ■ 参考リンク TSKaigi 2024 株式会社トレタの技術顧問に奥野賢太郎氏が就任 フロントエンドカンファレンス北海道2024 隅田川.dev vol.5 LT会 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック okunoの推し Singletonパターン 原義のSingletonパターンと現代のSingletonパターン 名前空間付きのグローバル変数なのでは？ 宣言したものだけで秩序があるグローバル変数 世界にひとつしか存在しないことを保証するSingleton 「ひとつであるべき」と「ひとつで十分」の違い Singletonってそもそも何？ Notchのコードは読みやすかった グローバルスコープが存在する言語でSingletonパターンは必要なのか？ 最近のWeb開発 グローバルステートの難しさ Singletonパターンうまく使えてますコメントお待ちしてます ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック lacolacoの推し Observerパターン Observerパターンの概要 情報伝達のPull型とPush型 原著を読まずに話しています addEventListener もObserverパターン IntersectionObserver が生まれたことでPull型からPush型になった Observerパターンは毎日どこかで使っている Observerパターンの大変なところ 監視する側はシンプルだけど、監視される側はシンプルにならない 複雑性を一か所に閉じ込める狙いもあるかもしれない Observerパターンを投入した話 イベントを発行する側と処理する側の依存関係を切る 依存関係を逆転させることでテストしやすくする 2番目の推し Commandパターン 「テスタビリティ」という価値観の上の原則とパターン 先人たちが作ったパターンに気づいてないだけで恩恵を受けている ■ 参考リンク #14 単一責任原則① 責任が単一であるってどういうこと？ ■...

■ トピック おたより紹介 「GoFデザインパターンは今でも役に立つのか？」 GoFデザインパターンとは？ レジェンドたちが書いた本 見たことないパターンもある Flyweightパターンは当たり前になってる Iteratorパターンはあまりにも定着している GoFデザインパターンとオブジェクト指向 そのパターンで解決したいことは変わってない ケント・ベック『実装パターン』 価値・原則・パターンの3層構造 価値・原則を踏まえてパターンを理解すると引き出しが増える OSSのコードを読むときにも役立つ 一般名詞っぽいパターンは判断に困ることもある パターンの名前だけを出して通じると思わないようにする 最近生まれた新しいデザインパターン 価値観が継続しているパターンは生き残っていく ■ 参考リンク オブジェクト指向における再利用のためのデザインパターン(改訂版） | SBクリエイティブ 実装パターン（日本語版） Implementation Patterns（原著） ■...

■ トピック コメントが腐っていく話 どういうコメントが腐りやすい？ 差分だけコードレビューするとコメントが見落とされがち 先にコメントを変えてからコードを直す コメントを書くかどうかと残すかどうかは別 Copilot用に書かれたコメント 何を書くのも自由だが、「残すかどうか」が重要 読み手のことを考えて書いたコメントは残すべきもの とにかくいったん書いてみたらいい。残すかどうかはあとで考える 自己流のコメント活用方法、おまちしてます ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック TODOコメントはパンの数と同じ 人々はTODOコメントを本当にTODOできているのか？ バグチケット管理とTODOコメントを紐づける コードの欠陥がなぜ直されていないのかが重要じゃないか？ いつ直すのかまで決めてTODOコメントを残す 「雑草は抜くべきだ」 from 『ルールズ・オブ・プログラミング』 作業前に目印をつける一時的なTODOコメント TODOコメントごとコピペされるつらみ コメントにはコードのつらみが詰まっている ■ 参考リンク O'Reilly Japan - リーダブルコード O'Reilly Japan - ルールズ・オブ・プログラミング ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 「コメントをちゃんと書きましょう」 コードの日本語訳のようなコメントは消してほしい 良くないコメントがあるよりは無い方がマシ コメントを書かないでいいようなコードを書きたい 「何を書いてはいけないのか」がわからないといけない コードスメル、消臭剤としてのコメント 情報として有益であっても消されるべきコメント 申し訳なさとともにコメントを書く 交通標識のように機能するコメント 読まれるべきコメントへの注意を引くためにはS/N比が大事 ■ 参考リンク O'Reilly Japan - リーダブルコード エンジニアのためのドキュメントライティング - JMAM 日本能率協会マネジメントセンター リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 『ルールズ・オブ・プログラミング』を勝手に紹介したい 令和に出るにふさわしい本 『ルールズ・オブ・プログラミング』の3種類の味わいかた 一般法則からスタートしていない新しい古典 ルール1 できるだけ単純であるべきだが、単純化してはいけない コードは本来解かねばならない問題空間の全体を解けなければならない テストよりもデバッグを重視する開発スタイル バグの原因と結果の距離をできるだけ近づける ゼルダBoWのデバッグを支えた `ZELDA_ERROR` 改めて「表明」をやっていこうと思った ■ 参考リンク O'Reilly Japan - ルールズ・オブ・プログラミング 「ゼルダの伝説 BotW」にバグが少ない理由 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 大規模リファクタリングの経験 他社システム連携のつらい話 システムの問題の原因を突き止める 仕様書どおりの実装であることを明らかにするための契約プログラミング 自分のミスか外部のミスかわからないとリファクタリングが難しい データベースを置き換えるリファクタリング Strategyパターンを実践した話 Strategyのインターフェースを設計するのが一番大変 バリデーションが多くて困ることはない ■ 参考リンク 契約プログラミング - Wikipedia 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022 - t_wada ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック tonakai4さんからのおたより紹介 規模のイメージ 小規模なリファクタリングとは？ diffが小さいからといって小規模な変更とは限らない 多く依存されている部分を変えるのは影響が大きい モジュールの可視性で依存関係を制限する リファクタリングの規模を抑えるための仕組みづくり その変更で何件のテストが落ちるか？ テストを落とすことからはじめる そろそろ小規模じゃなくなるライン 中規模になりそうなら分解して小規模に抑える 変更されてるファイルの数が多くても規模には関係ない ■ 参考リンク uhyo/eslint-plugin-import-access ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 単一責任原則に反したコードのリファクタリング アクターが重なりがちな例 顧客管理システムと単一責任原則 null埋めから単一責任原則の違反を見つける アクターが混ざってしまったコードを直すのは難しい 単一責任原則はコンウェイの法則から導かれている 現実世界をどうモデリングするか次第 単一責任原則はコードを書く前に考えたい あらゆるものが単一責任原則に見えてくる テストのモックと単一責任原則 SRPとDRYの駆け引きが腕の見せどころ 「うちのSRP」を聞きたい ■ 参考リンク PrinciplesOfOod Clean Architecture - アスキードワンゴ 単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter）...

■ トピック 単一責任原則はコードレビューで指摘する？ フロントエンド・バックエンドの言語が共通なときの単一責任原則 共通化すべきかどうかの判断基準もアクター UIデザインと単一責任原則 単一責任原則が適用できない場面を探すほうが難しい 「単一責任原則」の名前はもったいない？ 共通化って怖くない？ ユーティリティの責任は無限 単一責任原則が適用できない場面とは？ 無限のアクターに対応できるのは神 妥当な共通化を考える尺度 作っているもののアクターを理解する アクターで語るコードレビュー ■ 参考リンク PrinciplesOfOod Clean Architecture - アスキードワンゴ 単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter）...

■ トピック SOLID原則のなりたち 「単一責任」ってどういうこと？ 単一責任の勘違い 責任って何？ もともとはPrinciples of OODだった SOLID原則とオブジェクト指向 いまでもオブジェクト指向設計の原則は有効？ Clean Architectureから単一責任原則の定義を読む 「変更する理由がひとつ」ってどういうこと？ 責任はコードとアクターとの間の関係を表す UMLと単一責任原則 アクターが違うならコードを共通化してはいけない やることがひとつだからといって、単一責任になるとは限らない ■ 参考リンク PrinciplesOfOod Clean Architecture - アスキードワンゴ 単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter）...

■ トピック 複数形になると長い名前 短縮形+sを使う場面 ディレクトリ名の単複問題 内容物を示すディレクトリ名と、関連を示すディレクトリ名 ディレクトリ名の単複をわざわざ指摘することは少ない？ 変数名の単複 データベースのテーブル名が複数形になっている "repository" を扱うコードの書きにくさ "repos" はピンとこないが "repositories" はちょっと長い コレクションを表す変数の名前 "data" は複数形 コレクションのコレクションの名前付け ■ 参考リンク Ducks パターン GitHub APIの"repos" ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック おたよりの内容振り返り 「ユーティリティ」がゴミ箱になる 意味をなしていない「ユーティリティ」という名前をやめよう 具体性に欠ける名前を使うなら、厳格な規則で具体性を持たせる 内部的なライブラリとしてパッケージを分ける 一度共通化されたコードの責任が肥大化する テストを複雑にしてまで拡張する必要があるのか 共通化された関数のパラメータが増えるとき 切り出されたユーティリティを見直してさらに切り出す テストさえ書けていれば複雑になってもいいのか？ 「長すぎる関数」編での話の思い出し 複雑な関数のテストが十分だと確信できるのは書いた人だけ パラメータを増やした結果、中で条件分岐が増えるようなら共通化はやめておく 一度共通化されたコードをベタ書きに戻す これは質問の回答になっているのでしょうか？ ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは...

■ トピック おたよりを読む ユーティリティとは何か utils vs utilities shared とか domain とか もともとあるなにかの不便さを補うためにつくられる 言語そのものの不便さを補うためのユーティリティ そのままOSSにして公開してもいいようなコードをユーティリティに置く ドメインモデルの中で外部ライブラリを使いたくない ライブラリのラッパーとしてのユーティリティ アプリケーションの外側のかゆいところに手を届かせるためにある 「またユーティリティを作ってしまった」 ユーティリティは最後の手段 ■ 参考リンク ディレクトリ構成ベストプラクティス ~ Angularアプリを作り続けてわかったこと / FRONTEND CONFERENCE 2019 - Speaker Deck Webアプリケーション設計の第一歩はディレクトリの整理から / Encraft 1 - Speaker Deck ■...

■ トピック リファクタリングに対する意識の変化 「リファクタリングを背負う」 「これもまたリファクタリングだな」 日常にあふれるリファクタリング性を見出す 渋谷駅とリファクタリング リファラジの数字 いただいたコメント 自分が聞いておもしろいものをやっていきたい 「リファクタリング最近流行ってんな」になったらいい やってほしいネタのおたよりも募集しています ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 長すぎる関数をどう短くするか 「関数の抽出」 段落ごとに関数にする 名前を付けにくかったら切り出し方を間違ってそう まず段落を作るところからはじめる コードを一望するための工夫あれこれ ソースコードを印刷したことがある話 「問い合わせによる一時変数の置き換え」 長い関数はその中に名前がつけられていない部分がある 「コマンドによる関数の置き換え」 長すぎる関数 まとめ ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 長い関数はテストしにくい？ テストがない長い関数は理解が難しい 長くなってからではテストを書くのも難しい その関数でやっていることを後からどれだけ読み解けるか 短くしようとする姿勢がいいコードにつながりやすい 短くすることで逆に読みにくくなるケース より短いコードで解決したいという欲求 コードの長さは読む側だけの問題 意図からコードへの投影、コードから意図への復元 長い関数からは意図を読み落としやすい カバレッジを測りながらコードを読む 一行一行コードを読む だいたいパターンでしか読んでいない 長くなる前にテストを書いておこう（テストファースト） ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ - 秀和システム ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter）...

■ トピック 関数が長くて困ること 読めれば長くてもいいのか？ 長いコードを読みやすくする現代の工夫 長いコードは複雑になりやすい 段落をつくる ユニットテストのAAA 関連するコードの距離 並び替えから始める スコープを小さくしたい 長くて複雑なのが問題 やることを増やすと関数は長くなりがち 短いコードを目標にすることで副次的にコードが整理される 段落さえはっきりしていればどうとでもなる感覚 ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 重複コードの2種類の消え方 関数の抽出 共通化で必ずしもコード量が減るわけではない 抽出されたコードをどこにどう置くかで考えることが多い OSSのライブラリを作るようにリファクタリングする 切り出されたものへの依存が後から増えて困る あえて重複コードを生み出すケース ユニットテストと重複コード パラメータ化テスト ステートメントのスライド リファクタリングは手数がなんぼ 実装前の整地としてのリファクタリング Gitのブランチをどうデザインするか ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 重複コードは何が問題なのか 分解してから共通部分を見つける マジックナンバーと重複コード 数字を忘れていいなら変数にする意味がある 名前をつけてみたら重複かどうかがわかる 改めて名前をつけて同じになるなら重複かもしれない CSSのプロパティ宣言順を統一したらバンドルサイズが小さくなった話 重複コードの共通化の利点は可読性だけじゃない ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha CSSプロパティを自動ソートしただけで、CSSのファイルサイズを（少しだけ）減らせた話 | Ubie テックブログ ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

※ お詫び: 収録時のミスでlacolaco側の声が聞きづらい部分があります。 ■ トピック 重複コードはどのようにして生まれるか コードの見た目は違うけど重複しているコード すでにある再利用可能なコードに気づかない コミュニケーションが不足することで生まれる重複コード 再利用可能なパーツにアクセス可能かどうかが重要 重複コードはどのように消えていくか 見た目が似てるけど本当は違った重複もどき 中途半端に似たコードがよかれと思って共通化される ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック どういう名前をリネームすることになるか "And" や "With" のあるある 名前をコロコロ変えることは問題か？ 具体的すぎる名前は二重管理になる 名前を変えないことにも意味がある diffの美しさ あとからリネームできるからといって適当に始めてはいけない ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

■ トピック 名前にはルールが必要？ 「英語として自然に読める」というルールについて "regist" 問題 命名規則の前提には文脈がある "get"と"fetch"のニュアンスの違い 語彙をあえて絞る、英語のサブセットのようなもの 規則がわからないと自分のコードを書き加えられない ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。