リファクタリングとともに生きるラジオ リファラジ
-
- テクノロジー
-
三度の飯よりリファクタリングが好きな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
-
#24 GoF② 世界はObserverパターンで動いている
■ トピック
lacolacoの推し Observerパターン
Observerパターンの概要
情報伝達のPull型とPush型
原著を読まずに話しています
addEventListener もObserverパターン
IntersectionObserver が生まれたことでPull型からPush型になった
Observerパターンは毎日どこかで使っている
Observerパターンの大変なところ
監視する側はシンプルだけど、監視される側はシンプルにならない
複雑性を一か所に閉じ込める狙いもあるかもしれない
Observerパターンを投入した話
イベントを発行する側と処理する側の依存関係を切る
依存関係を逆転させることでテストしやすくする
2番目の推し Commandパターン
「テスタビリティ」という価値観の上の原則とパターン
先人たちが作ったパターンに気づいてないだけで恩恵を受けている
■ 参考リンク
#14 単一責任原則① 責任が単一であるってどういうこと?
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。 -
#23 GoF① GoFデザインパターンは今でも役に立つのか?
■ トピック
おたより紹介
「GoFデザインパターンは今でも役に立つのか?」
GoFデザインパターンとは?
レジェンドたちが書いた本
見たことないパターンもある
Flyweightパターンは当たり前になってる
Iteratorパターンはあまりにも定着している
GoFデザインパターンとオブジェクト指向
そのパターンで解決したいことは変わってない
ケント・ベック『実装パターン』
価値・原則・パターンの3層構造
価値・原則を踏まえてパターンを理解すると引き出しが増える
OSSのコードを読むときにも役立つ
一般名詞っぽいパターンは判断に困ることもある
パターンの名前だけを出して通じると思わないようにする
最近生まれた新しいデザインパターン
価値観が継続しているパターンは生き残っていく
■ 参考リンク
オブジェクト指向における再利用のためのデザインパターン(改訂版) | SBクリエイティブ
実装パターン(日本語版)
Implementation Patterns(原著)
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。 -
#22 コメント③ 書くべきコメントよりも残すべきコメントについて考える
■ トピック
コメントが腐っていく話
どういうコメントが腐りやすい?
差分だけコードレビューするとコメントが見落とされがち
先にコメントを変えてからコードを直す
コメントを書くかどうかと残すかどうかは別
Copilot用に書かれたコメント
何を書くのも自由だが、「残すかどうか」が重要
読み手のことを考えて書いたコメントは残すべきもの
とにかくいったん書いてみたらいい。残すかどうかはあとで考える
自己流のコメント活用方法、おまちしてます
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。 -
#21 コメント② TODOコメントを本当にTODOするためのテクニック
■ トピック
TODOコメントはパンの数と同じ
人々はTODOコメントを本当にTODOできているのか?
バグチケット管理とTODOコメントを紐づける
コードの欠陥がなぜ直されていないのかが重要じゃないか?
いつ直すのかまで決めてTODOコメントを残す
「雑草は抜くべきだ」 from 『ルールズ・オブ・プログラミング』
作業前に目印をつける一時的なTODOコメント
TODOコメントごとコピペされるつらみ
コメントにはコードのつらみが詰まっている
■ 参考リンク
O'Reilly Japan - リーダブルコード
O'Reilly Japan - ルールズ・オブ・プログラミング
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。 -
#20 コメント① コメントを「ちゃんと書く」って何?
■ トピック
「コメントをちゃんと書きましょう」
コードの日本語訳のようなコメントは消してほしい
良くないコメントがあるよりは無い方がマシ
コメントを書かないでいいようなコードを書きたい
「何を書いてはいけないのか」がわからないといけない
コードスメル、消臭剤としてのコメント
情報として有益であっても消されるべきコメント
申し訳なさとともにコメントを書く
交通標識のように機能するコメント
読まれるべきコメントへの注意を引くためにはS/N比が大事
■ 参考リンク
O'Reilly Japan - リーダブルコード
エンジニアのためのドキュメントライティング - JMAM 日本能率協会マネジメントセンター
リファクタリング(第2版) 既存のコードを安全に改善する | Ohmsha
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。 -
#19 雑談回 『ルールズ・オブ・プログラミング』を紹介したい!
■ トピック
『ルールズ・オブ・プログラミング』を勝手に紹介したい
令和に出るにふさわしい本
『ルールズ・オブ・プログラミング』の3種類の味わいかた
一般法則からスタートしていない新しい古典
ルール1 できるだけ単純であるべきだが、単純化してはいけない
コードは本来解かねばならない問題空間の全体を解けなければならない
テストよりもデバッグを重視する開発スタイル
バグの原因と結果の距離をできるだけ近づける
ゼルダBoWのデバッグを支えた `ZELDA_ERROR`
改めて「表明」をやっていこうと思った
■ 参考リンク
O'Reilly Japan - ルールズ・オブ・プログラミング
「ゼルダの伝説 BotW」にバグが少ない理由
■ おたよりフォーム
https://forms.gle/RYUG7T4ctmF7Srf36
■ X(Twitter)
https://twitter.com/refactoradio
ハッシュタグは #リファラジ です。
カスタマーレビュー
面白すぎる!
勉強になるし面白いです!
ランニングしながら聞いてます!
出来たらずっと続いて欲しい〜
ワシもリファクタリングが好き
まさかリファクタリングが主題のチャンネルがあるとは。 わしは個人でアプリ作って食ってるが、個人でもリファクタリングの重要性はいやってほど感じてる。チームでやってる人にとっては最重要なスキルじゃないだろか。 そんなスキルのとても濃い話題が聞ける。しかもレベルは相当に高い。YouTubeやブログでは見たことのない深さとレベルだと思う。リファクタリングはプログラミング以外にも応用できる考え方だと思うので、そうした話も聞いてみたい。