Dev-Here> Review-Ready Design Blog
レビューの指摘、
毎回イチから書くのダルくない？🥺
「AIが書いたんで」ってそのまま出してくる子いるじゃん？ 5歳児でも分かるレベルまで噛み砕いてあるから、「これ読んで分かんなかったら知らんよ？」って送りつけちゃって。浮いた時間、自分のコードに使お？
安藤 れあ
毎回同じ指摘書くのダルいじゃん？🫶 リンク1本送って、あとはれあに任せちゃって✨
> Copy & Paste
そのまま貼れるレビュー文
長文で説教しなくていいよ。PRやSlackに貼って、記事で前提を揃えてから直してもらえばOK。
この変更、実装を足す前に「このクラスの仕事が何個あるか」を整理したほうがいいです。まずこれを読んでから分け方を見直してください。 https://dev-here.tech/blog/god-class-and-single-responsibility-principle
今の作りだと相手の都合にべったりで、差し替えた瞬間に広く壊れます。依存の向きを先に揃えたいです。これを前提にもう一度見直してください。 https://dev-here.tech/blog/coupling-and-dependency-inversion-principle
この名前だと、読む人が中身を開くまで意味が分かりません。何をするものかが名前だけで伝わる状態に直したいです。先にこれを読んで整理してください。 https://dev-here.tech/blog/mysterious-name-and-intention-revealing-names
この処理、直してるんじゃなくて隠してます。失敗したことを呼び出し側が分かる形に変えたいです。まずこの観点を揃えたいです。 https://dev-here.tech/blog/exception-swallowing-and-responsible-handling
「責務混ざってない？」「依存の向き大丈夫？」みたいなレビュー、毎回口で言わなくてよくなる。チェックリストに記事リンクもついてるから、指摘の根拠も一緒に渡せるんだよね。
やることは1個だけ
リポジトリの templates/github/PULL_REQUEST_TEMPLATE.md を自分のリポジトリの .github/ にコピーするだけ。PR作るたびに設計チェックリストが自動で出るよ。
中身ただのMarkdownだからコードが動いたりしないよ。ライセンスもCC BY 4.0で商用OK。安心して持ってって。
> Ready-made Sets
送りつけ3本セット
毎回1本ずつ選ぶのがダルいなら、相手の状態ごとにまとめて送ればいいじゃん。
とりあえず動くコードから一段上がってほしいときに送るセット。責務、命名、例外の3つを先に揃える。
なんでダメかは言われるけど、どこから直せばいいか分からない人向け。設計判断の軸を先に入れる。
モヤっとするけど説明が難しいときに、自分のレビュー観点を整えるためのセット。送る側にも効くやつ。
> Symptoms
症状から探す
原則名で探さなくていいよ。現場で実際に出る「これヤバくない？」から辿れば十分。
責務が混ざってる、追加のたびに既存が死にかける、Controllerが全部やってる。そういうやつ。
名前がふわふわ、なんでその設計にしたか残ってない、層をまたいで参照が暴れてる。レビューが噛み合わない原因になりがち。
例外を握りつぶす、先回りでまとめすぎる、どこかが書き換える前提で状態を持つ。あとで全員しんどくなるやつ。
> All Articles
記事一覧
ここからは全部入り。症状から探してもいいし、気になるタイトルから直接読んでもいいよ。
