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

■ トピック


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

ハッシュタグは #リファラジ です。