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

■ トピック 今年の抱負・展望 2024年はじめてやったこと 函館に初めて行ってきたlacolaco 小学生からの質問が人生で一番緊張した まだ行ったことない場所で登壇したい いままでにやったことある言語 今年新しく学びたい言語 AIに達人を奪われていくのか？ AIには究極に便利な道具であってほしい 次回からは通常運転 ■ 参考リンク HAKODATE Developer Conference 2024 BuriKaigi すごいHaskell たのしく学ぼう！ ■ おたよりフォーム...

■ トピック おたより・コメント紹介 不要コードの削除 人間とAI、安心と安全 削除はコードベースを理解してないとできない テストは安心のために書く コーディング規約をどう守ってもらうか リファクタリングかそうじゃないか 設計の擬人化とTRPG おたより・コメント・ハッシュタグはすべて読んでおります 次回に続く ■ 参考リンク PHPカンファレンス福岡2023でのlacolacoの発表資料 ■ おたよりフォーム https://forms.gle/RYUG7T4...

■ トピック あけましておめでとうございます 前回のネタ出しのふりかえり 更新系のHTTP APIスキーマ POST/PUTのレスポンス リファクタリングのゴール 『プログラマー脳』やってない話 お寿司到着 『Good Code, Bad Code』を読みたい 実務ベースの話 みんなのJavaのイメージが古い 新しく学んだ言語プレゼン回 達人への道 どうやってリファクタリングを業務に組み込むか 木こりのジレンマからどう立ち直るか 次回に続きます ■ 参考...

■ トピック リファラジ1年間の数字 4万再生 全話聞いている人が多い ブログで紹介されたところで急にリスナーが増えた 人気のエピソード 『ルールズ・オブ・プログラミング』の回 サブタイトルの決め方 来年への抱負 2025年もよろしくお願いします ■ 参考リンク エンジニア必聴の最高の技術ラジオ「リファラジ」を広めたい Voicy 2024年11月の【IT/エンジニア】の人気チャンネル 30位 ■ おたよりフォーム https://forms.gle/RYUG7T...

■ トピック ドメインとWebのセキュリティ リダイレクトいつ外せるの問題 印刷されてしまったURL ドメインの終活 おしゃれなドメインは高いがち Javaのパッケージ名とドメイン ドメインの影響範囲バカでかい 基本的に変えたくない エンジニアのほうから言い出すことは少ない ドメイン変えるのは会社名変えるくらい大変なのでは あからさまに一時的であることを示すドメインを使う ドメイン名変更の方法論を磨けていない反省 ユーザ...

■ トピック ドメインとWebサイトの名前 ドメインもまた名前 ちょっと変わったTLDの経験 夢の okunokenta.ro, lacola.co TLDの意味を意識する？ 増え続けているドメイン名 jp.sharp の事例 note、任天堂の事例 なぜ人はドメインにこだわるのか？ Webサイト名と完全一致するドメイン 名前付けの中でも難しい命名 .new ドメインはずるい ドメイン取れるのか？からWebサービスは始まる 次回は「ドメインを変更する」話 ■ 参考リンク ジ...

■ トピック 1冊目『プリンシプル オブ プログラミング』 もともとはブログだった 何ができたらプログラマーって名乗っていいのか？ 基本的な原理原則をカタログ的にまとめてくれている 次に読むべき本がわかる 職業としてのプログラマーに必要な知識 2冊目『.NETのエンタープライズアプリケーションアーキテクチャ』は絶版本 とにかくエンタープライズ 大規模なアプリケーションをどう作るか okunoを支えるバイブル 3冊目『はじめ...

■ トピック おすすめ本紹介をしたくなった理由 1冊目『プログラマが知るべき97のこと』 何したらプログラマーになれるんだ？ 独学でもやれる勇気をくれる本 個人にフィーチャーする本への憧れ 2冊目『Clean Architecture』 タイトルで誤解されてがち よく使う設計原理・原則のリファレンスとして語彙を増やせる 「叫ぶアーキテクチャ」 どこまでいってもボブおじさんには追いつかない 3冊目『達人プログラマー』 身につけるべき習...

■ トピック 祝・第50回 最新情報を追跡するルーチン インプットのプッシュ型とプル型 メールの未読ゼロ GitHubからの通知 Discordでキャッチアップする ちゃんと読みたいものは時間を見つけてプル型で SNSでの情報収集 英語原文でのインプット Zennにトレンドを探しにいく エラーの解決方法の探し方 具体と抽象を行き来しないと解決できない AIの使い方 ■ 参考リンク JSer.info Blog | web.dev ■ おたよりフォーム https://forms.g...

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック リファクタリングモードに入ってまずやること 名前を変えてみる 既存コードをいったん消して書き直してみる コメントを書き足すだけでもリファクタリング 「3つ目」が降ってくるとき 趣味と業務 知識が不確実だと備えが必要 いつでもリファクタリングはじめられるためにやっていること ディレクトリ構造をきれいにしておく 新しいメンバーからのフィードバックは大...

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック 既存コードを触っていてリファクタリングモードに切り替わるタイミング 「なんかリファクタリングするところないかな〜」 既存のコードを掌握するためのリファクタリング レビュー基準が変化することで崩れる一貫性を見直す コードベースとの関係性とリファクタリング 変更している途中でブレーキがかかってリファクタリングに切り替わる まさしく「コードスメル」...

※ お詫び: 収録時のミスでlacolacoの音質が悪いです。 ■ トピック リファクタリングモード モードの切り替わりのタイミング 耐えられなくなる閾値 「こんなつもりじゃなかったんだけどな」 どこまで行けるかぶち当たりに行く グリーンになる前にリファクタリングしてしまう悪い癖 名前を真剣に考え始めるタイミングの違い リファクタリングモードから帰ってこない チーム開発ならいったん議論してから 結局「驚き最小の原則」 書く...

■ トピック AngularはなぜDIを備えている？ GoogleはDIがやりたくてAngularJSを作った？ JavaScriptの世界でOOPのプラクティスを実現したかったんじゃないか 型で依存性の注入をやるためのTypeScript化 AtScriptという要件 AngularはDecoratorsが標準化されなくても困らない Angularを使いたくなる理由 Angularが与えた影響 原則を強制させるためのフレームワーク AngularはDIフレームワークである（過言？） 空気のようになってい...

■ トピック 依存性の注入とは何か？ インスタンス作成の詳細を隠蔽したい コンストラクタに依存するインスタンスを渡していれば依存性の注入と言えるか サービスロケーターパターンとの違い DIはテストのためにあるのか？ 結局はカプセル化と隠蔽 DIもDIPを実践する手段のひとつに過ぎない ■ 参考リンク #42 カプセル化① 「秘密」と「隠蔽」 カプセル化は人形遊びで鍛える ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36...

■ トピック SOLIDのD、依存性逆転の原則 依存性って何？逆転って何？ 依存関係とクラス図 インターフェースと実装の分離 知らないうちにやってたDIP 依存性の注入との混乱 駆け出しでDIPを学ぶべきか？ 開発がスケールするためにはDIPが必要そう 「いつまで経っても変更作業が終わりません」 カプセル化とDIP ■ 参考リンク #14 単一責任原則① 責任が単一であるってどういうこと？ 『レガシーコード改善ガイド』マイケル・C・フェザ...

■ トピック 引数が変わりやすい関数は秘密を隠蔽できていない シグニチャがころころ変わる関数はリファクタリングに失敗している データとロジックのカプセル化のツールとしてのクラス 何を隠蔽したいのか？で何を使うかを考える 委譲の隠蔽、仲介人の除去 「デメテルの法則」にのめり込みすぎたコード データベースのJOINが透けて見えるJSON 「時には役に立つデメテルの提案」 経験を積んで変わった『リファクタリング』の読み方...

■ トピック カプセル化との出会い 「カプセル化って何ですか？」 カプセル化とクラスベースオブジェクト指向 カプセル化とモジュール化は違う カプセル化のキモは隠蔽である 「隠蔽すべき秘密を持っているか？」 ソースコード上の「秘密」の感覚と擬人化 ミューテーション前提のカプセル化 急速に重複するロジック 続きは後編へ ■ 参考リンク リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha ■ おたよりフォーム...

■ トピック lacolacoが最近キーボードを買った話 キーボードの交換と破壊的変更 新しいマシンを買ってもすぐに使わずマイグレーション期間を設ける okunoがトラックパッドを買った話 職場と家で腕の動きを揃えたい 使えなくなったUSBケーブルはデッドコード削除しよう 次回から『リファクタリング』の第7章「カプセル化」を読みます ■ 参考リンク DrunkDeerのキーボードを買った | Marginalia リファクタリング（第2版） 既存のコ...

■ トピック バリデーションしてますか？ フォームのバリデーションとAPIのバリデーション zod, valibotで変わったバリデーションの書き方 バリデーションの種類の違い 仕様をあとから変更することの難しさ [object Object] の恐怖 クライアント側での防御的なレスポンスバリデーション スキーマと実装の一貫性をどう保証するか？ 防御的に実装しても損はしない バリデーションがあることでリファクタリングしやすくなる ■ 参考リン...

■ トピック GraphQLを使い始めたモチベーション スキーマ駆動開発 スキーマ中心の分業はだいぶメジャーになった 手書きのスキーマがメンテナンスしやすいかどうか Excelの「電文仕様書」 「必須」パラメータの定義の悩み スキーマ記述言語としてGraphQLを気に入っている話 zod, valibot バリデータを書くとスキーマが手に入る フロントエンドでもバックエンドでもないところでスキーマを書けるのが重要 結局TypeScriptの型がスキー...

■ トピック HTTP通信どうしてる？ APIエンドポイントのURL設計 APIのバージョニングの是非 APIの破壊的変更をどう避ける？ v3が生まれたらおしまい OSSのやりかたは参考になる API仕様の変更のしやすさ URLは使う登場人物が多いから厄介 ■ 参考リンク O'Reilly Japan - 進化的アーキテクチャ ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ハッシュタグは #リフ...

■ トピック YAGNIってDRYと対立する原則なのか？ YAGNIとどこで出会った？ 抽象化を身につけ始めた初心者にYAGNIが刺さる DRYに従うことこそがYAGNIの原則を実現するのでは？ 「何が必要か」を判断するのは知識 まだ不確実な知識を取り込んだDRYはYAGNIに反する 知識が間違ってるかどうかは話してみないとわからない 原則を守ってコードを書くのは他人と円滑に仕事をするため 将来を心配しすぎたコード DRYを守った結果YAGNIに反す...

■ トピック Google Testing Blogの気になる記事 早すぎる抽象化によるDRYの危険性 DRYに対置されるのはYAGNIなのか？ DRY原則はいいコードを導く？ DRYは悪者なのか？ 「すべての知識は、システム内で単一の、明確な、信頼できる表現を持たなければならない」 Google Testing Blogで否定されたDRY原則はそもそも原典でも否定されている ドキュメントの二重化 異なる知識から同じ表現が生まれることはありえる DRYに反してるかどう...

■ トピック Publickeyに掲載された記事の紹介 命名的問題と構造的問題 読みやすいと思ったコードのほうが読解を間違っていた 間違った名前を間違ったまま受け取ってしまっている 「読めた気になれる」コードは間違いやすい 確かな名前を頼りに難しいコードを読むことはできる 「コードの書き手との信頼関係」 防御的に読むモードに切り替わる わからないほうが誤解されるよりマシ ぜひ元の記事を読んでみてください ■ 参考リンク...

■ トピック Diffの将来を妄想する GitHubは完成形なのか？ Diffは結局パッチファイル 差分が取れるものはすべてDiffにしてしまうのでは？ Yet Another GitHubを想像する Gitの次はどうやったら生まれるか？ プログラミングが音声入力になったら？ 再現性がなければバージョン管理をしても意味がなさそう 結局ロールバックしたい GitHubに依存しすぎた開発にも反省するところがある 特にオチのない話でした ■ 参考リンク Git トラン...