■ トピック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」を聞きたい■ 参考リンクPrinciplesOfOodClean Architecture - アスキードワンゴ単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場■ おたよりフォームhttps://forms.gle/RYUG7T4ctmF7Srf36■ X（Twitter） https://twitter.com/refactoradioハッシュタグは #リファラジ です。

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

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

■ トピック複数形になると長い名前短縮形+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 utilitiesshared とか domain とかもともとあるなにかの不便さを補うためにつくられる言語そのものの不便さを補うためのユーティリティそのままOSSにして公開してもいいようなコードをユーティリティに置くドメインモデルの中で外部ライブラリを使いたくないライブラリのラッパーとしてのユーティリティアプリケーションの外側のかゆいところに手を届かせるためにある「またユーティリティを作ってしまった」ユーティリティは最後の手段■ 参考リンクディレクトリ構成ベストプラクティス ~ Angularアプリを作り続けてわかったこと / FRONTEND CONFERENCE 2019 - Speaker DeckWebアプリケーション設計の第一歩はディレクトリの整理から / Encraft 1 - Speaker Deck■ おたよりフォームhttps://forms.gle/RYUG7T4ctmF7Srf36■ X（Twitter） https://twitter.com/refactoradioハッシュタグは #リファラジ です。

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

■ トピック関数が長くて困ること読めれば長くてもいいのか？長いコードを読みやすくする現代の工夫長いコードは複雑になりやすい段落をつくるユニットテストの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版） 既存のコードを安全に改善する | OhmshaCSSプロパティを自動ソートしただけで、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ハッシュタグは #リファラジ です。

■ トピックごあいさつラジオのコンセプトプログラミングと名前変えられる名前、変えられない名前名前と意味■ おたよりフォームhttps://forms.gle/RYUG7T4ctmF7Srf36■ X（Twitter） https://twitter.com/refactoradioハッシュタグは #リファラジ です。