Claim Ownershipリファクタリングとともに生きるラジオ
Subscribed: 8Played: 69
Subscribe
© リファラジ
Description
三度の飯よりリファクタリングが好きな2人がリファクタリングについてゆるく楽しく雑談する様子をお届けするラジオです。
毎週更新を目指します。チャンネルフォローしてもらえると嬉しいです。
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X（Twitter）
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。
■ YouTube
https://www.youtube.com/@refactoradio
■ lacolaco
https://twitter.com/laco2net
■ okunokentaro
https://twitter.com/okunokentaro
毎週更新を目指します。チャンネルフォローしてもらえると嬉しいです。
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X（Twitter）
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。
■ YouTube
https://www.youtube.com/@refactoradio
■ lacolaco
https://twitter.com/laco2net
■ okunokentaro
https://twitter.com/okunokentaro
22 Episodes
Reverse
■ トピック
コメントが腐っていく話
どういうコメントが腐りやすい？
差分だけコードレビューするとコメントが見落とされがち
先にコメントを変えてからコードを直す
コメントを書くかどうかと残すかどうかは別
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）
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。
■ トピック
単一責任原則はコードレビューで指摘する？
フロントエンド・バックエンドの言語が共通なときの単一責任原則
共通化すべきかどうかの判断基準もアクター
UIデザインと単一責任原則
単一責任原則が適用できない場面を探すほうが難しい
「単一責任原則」の名前はもったいない？
共通化って怖くない？
ユーティリティの責任は無限
単一責任原則が適用できない場面とは？
無限のアクターに対応できるのは神
妥当な共通化を考える尺度
作っているもののアクターを理解する
アクターで語るコードレビュー
■ 参考リンク
PrinciplesOfOod
Clean Architecture - アスキードワンゴ
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X（Twitter）
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。
■ トピック
SOLID原則のなりたち
「単一責任」ってどういうこと？
単一責任の勘違い
責任って何？
もともとはPrinciples of OODだった
SOLID原則とオブジェクト指向
いまでもオブジェクト指向設計の原則は有効？
Clean Architectureから単一責任原則の定義を読む
「変更する理由がひとつ」ってどういうこと？
責任はコードとアクターとの間の関係を表す
UMLと単一責任原則
アクターが違うならコードを共通化してはいけない
やることがひとつだからといって、単一責任になるとは限らない
■ 参考リンク
PrinciplesOfOod
Clean 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 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
ハッシュタグは #リファラジ です。
■ トピック
リファクタリングに対する意識の変化
「リファクタリングを背負う」
「これもまたリファクタリングだな」
日常にあふれるリファクタリング性を見出す
渋谷駅とリファクタリング
リファラジの数字
いただいたコメント
自分が聞いておもしろいものをやっていきたい
「リファクタリング最近流行ってんな」になったらいい
やってほしいネタのおたよりも募集しています
■ おたよりフォーム
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版） 既存のコードを安全に改善する | 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
ハッシュタグは #リファラジ です。
Comments
Download from Google Play
Download from App Store
United States