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

■ トピック われわれはどのようにDiffを作っているのか？ laco: ブランチのDiffをいったんすべて並べてまとめ直す 注目すべきコミットをわかりやすくする okuno: 1コミットにすべて詰めこんで検証したうえで消して別ブランチで書き直す リリース戦略とプルリクエストの作り方 仮コミットと仮ブランチ 書くべきコミットはなく、残すべきコミットを考える ログに残されるコミットの選抜試験 これもまたテスト駆動開発なのでは？ 読み...

■ トピック Diffのデザインに気をつけている話 GitHubのプルリクエストで見るDiff OSSのチェンジログからみるDiff なぜプルリクエストの単位でDiffを見るのか Diffから意図を取り出すのは難しい 履き違えられたボーイスカウトルール 関係ないファイルの「ついで直し」はボーイスカウトではない リバートされることを考えて変更差分を作る 「リリースノートを作る気持ちになってごらん」 他の人のためのテキスト・ドキュメントを作...

■ トピック コロケーション（co-location）って何？ テストコードのファイルをどこに置くか 同じファイルにテストを書くところ（In-source Testing）まで来た テストとテスト対象は近ければ近いほどいい？ 『レガシーコード改善ガイド』におけるコロケーションの話 デプロイのためのファイル配置 glob-ability高い命名規則がが定まればコロケーションができる OSSのコードにはいまでもtestディレクトリをよく見る コロケーションの...

■ トピック おたよりをいただきました ファイル・ディレクトリ周りで参考にしているルール フレームワークの基本的なディレクトリ構造 ディレクトリベースドルーティング ファイルと変数の命名規則は分けたい 設定より規約、の振り子 考えることを減らすというトレンド ファイル名についてのコントロールを持っていたい globbableなファイルの命名 `foo.spec.js` 形式（第二拡張子？） マジック（マジカル）ナンバー7±2...

■ トピック 引き続き居酒屋からお送りします ここまでのネタ出しのまとめ 公開収録の野望 『御社のリファクタリング』回をやりたい リファクタリング自慢したいおたよりをお待ちしています ゲームで学ぶリファクタリング 美女木ジャンクション リアルワールドで見かけたリファクタリング モチベーションの源泉 想像で語るアクアリウムのリファクタリング 結局3回分の撮れ高になりました ■ 参考リンク Shinjuku.rb#92をClassiで開催...

■ トピック 引き続き居酒屋からお送りします コードの読み方のネタ 『プログラマー脳』の話 訂正）『プログラマー脳』はITエンジニア本大賞2024のベスト10でした 「読み方」の学び方 リファラジの聞かれ方 「名前」リターンズ SOLIDとともに生きているか？ すべてがOになる ■ 参考リンク プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ - 秀和システム O'Reilly Japan - ルールズ・オブ・プログ...

■ トピック 都内某所の居酒屋からお送りします 今後に向けてのネタ出し会議 「ともに生きている」話をしないと意味がない APIスキーマのリファクタリング リファラジの録り方 最近読んだOSS ちくわの磯辺揚げ・焼きそば ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リファラジ です。

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

■ トピック okunoの推し Singletonパターン 原義のSingletonパターンと現代のSingletonパターン 名前空間付きのグローバル変数なのでは？ 宣言したものだけで秩序があるグローバル変数 世界にひとつしか存在しないことを保証するSingleton 「ひとつであるべき」と「ひとつで十分」の違い Singletonってそもそも何？ Notchのコードは読みやすかった グローバルスコープが存在する言語でSingletonパターンは必要なのか？ 最近のWeb開...

■ トピック lacolacoの推し Observerパターン Observerパターンの概要 情報伝達のPull型とPush型 原著を読まずに話しています addEventListener もObserverパターン IntersectionObserver が生まれたことでPull型からPush型になった Observerパターンは毎日どこかで使っている Observerパターンの大変なところ 監視する側はシンプルだけど、監視される側はシンプルにならない 複雑性を一か所に閉じ込める狙いもあるかもしれない Ob...

■ トピック おたより紹介 「GoFデザインパターンは今でも役に立つのか？」 GoFデザインパターンとは？ レジェンドたちが書いた本 見たことないパターンもある Flyweightパターンは当たり前になってる Iteratorパターンはあまりにも定着している GoFデザインパターンとオブジェクト指向 そのパターンで解決したいことは変わってない ケント・ベック『実装パターン』 価値・原則・パターンの3層構造 価値・原則を踏まえてパターンを...

■ トピック コメントが腐っていく話 どういうコメントが腐りやすい？ 差分だけコードレビューするとコメントが見落とされがち 先にコメントを変えてからコードを直す コメントを書くかどうかと残すかどうかは別 Copilot用に書かれたコメント 何を書くのも自由だが、「残すかどうか」が重要 読み手のことを考えて書いたコメントは残すべきもの とにかくいったん書いてみたらいい。残すかどうかはあとで考える 自己流のコメント活用...

■ トピック TODOコメントはパンの数と同じ 人々はTODOコメントを本当にTODOできているのか？ バグチケット管理とTODOコメントを紐づける コードの欠陥がなぜ直されていないのかが重要じゃないか？ いつ直すのかまで決めてTODOコメントを残す 「雑草は抜くべきだ」 from 『ルールズ・オブ・プログラミング』 作業前に目印をつける一時的なTODOコメント TODOコメントごとコピペされるつらみ コメントにはコードのつらみが詰まってい...

■ トピック 「コメントをちゃんと書きましょう」 コードの日本語訳のようなコメントは消してほしい 良くないコメントがあるよりは無い方がマシ コメントを書かないでいいようなコードを書きたい 「何を書いてはいけないのか」がわからないといけない コードスメル、消臭剤としてのコメント 情報として有益であっても消されるべきコメント 申し訳なさとともにコメントを書く 交通標識のように機能するコメント 読まれるべきコメント...

■ トピック 『ルールズ・オブ・プログラミング』を勝手に紹介したい 令和に出るにふさわしい本 『ルールズ・オブ・プログラミング』の3種類の味わいかた 一般法則からスタートしていない新しい古典 ルール1 できるだけ単純であるべきだが、単純化してはいけない コードは本来解かねばならない問題空間の全体を解けなければならない テストよりもデバッグを重視する開発スタイル バグの原因と結果の距離をできるだけ近づける ゼルダ...

■ トピック 大規模リファクタリングの経験 他社システム連携のつらい話 システムの問題の原因を突き止める 仕様書どおりの実装であることを明らかにするための契約プログラミング 自分のミスか外部のミスかわからないとリファクタリングが難しい データベースを置き換えるリファクタリング Strategyパターンを実践した話 Strategyのインターフェースを設計するのが一番大変 バリデーションが多くて困ることはない ■ 参考リンク 契...

■ トピック tonakai4さんからのおたより紹介 規模のイメージ 小規模なリファクタリングとは？ diffが小さいからといって小規模な変更とは限らない 多く依存されている部分を変えるのは影響が大きい モジュールの可視性で依存関係を制限する リファクタリングの規模を抑えるための仕組みづくり その変更で何件のテストが落ちるか？ テストを落とすことからはじめる そろそろ小規模じゃなくなるライン 中規模になりそうなら分解して...

■ トピック 単一責任原則に反したコードのリファクタリング アクターが重なりがちな例 顧客管理システムと単一責任原則 null埋めから単一責任原則の違反を見つける アクターが混ざってしまったコードを直すのは難しい 単一責任原則はコンウェイの法則から導かれている 現実世界をどうモデリングするか次第 単一責任原則はコードを書く前に考えたい あらゆるものが単一責任原則に見えてくる テストのモックと単一責任原則 SRPとDRY...

■ トピック 単一責任原則はコードレビューで指摘する？ フロントエンド・バックエンドの言語が共通なときの単一責任原則 共通化すべきかどうかの判断基準もアクター UIデザインと単一責任原則 単一責任原則が適用できない場面を探すほうが難しい 「単一責任原則」の名前はもったいない？ 共通化って怖くない？ ユーティリティの責任は無限 単一責任原則が適用できない場面とは？ 無限のアクターに対応できるのは神 妥当な共通化を...

■ トピック SOLID原則のなりたち 「単一責任」ってどういうこと？ 単一責任の勘違い 責任って何？ もともとはPrinciples of OODだった SOLID原則とオブジェクト指向 いまでもオブジェクト指向設計の原則は有効？ Clean Architectureから単一責任原則の定義を読む 「変更する理由がひとつ」ってどういうこと？ 責任はコードとアクターとの間の関係を表す UMLと単一責任原則 アクターが違うならコードを共通化してはいけない やるこ...

■ トピック 複数形になると長い名前 短縮形+sを使う場面 ディレクトリ名の単複問題 内容物を示すディレクトリ名と、関連を示すディレクトリ名 ディレクトリ名の単複をわざわざ指摘することは少ない？ 変数名の単複 データベースのテーブル名が複数形になっている "repository" を扱うコードの書きにくさ "repos" はピンとこないが "repositories" はちょっと長い コレクションを表す変数の名前 &quo...

■ トピック おたよりの内容振り返り 「ユーティリティ」がゴミ箱になる 意味をなしていない「ユーティリティ」という名前をやめよう 具体性に欠ける名前を使うなら、厳格な規則で具体性を持たせる 内部的なライブラリとしてパッケージを分ける 一度共通化されたコードの責任が肥大化する テストを複雑にしてまで拡張する必要があるのか 共通化された関数のパラメータが増えるとき 切り出されたユーティリティを見直してさらに切り...

■ トピック おたよりを読む ユーティリティとは何か utils vs utilities shared とか domain とか もともとあるなにかの不便さを補うためにつくられる 言語そのものの不便さを補うためのユーティリティ そのままOSSにして公開してもいいようなコードをユーティリティに置く ドメインモデルの中で外部ライブラリを使いたくない ライブラリのラッパーとしてのユーティリティ アプリケーションの外側のかゆいところに手を届かせるため...

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

■ トピック 長すぎる関数をどう短くするか 「関数の抽出」 段落ごとに関数にする 名前を付けにくかったら切り出し方を間違ってそう まず段落を作るところからはじめる コードを一望するための工夫あれこれ ソースコードを印刷したことがある話 「問い合わせによる一時変数の置き換え」 長い関数はその中に名前がつけられていない部分がある 「コマンドによる関数の置き換え」 長すぎる関数 まとめ ■ 参考リンク リファクタリング（...