Webフロントエンドのコードレビューメモ
Webフロントエンドのコードレビューをしているときに考えていることについて書きます。
毎日1記事投稿、1記事30分という制約を課していますので、本記事は完璧ではありません。(言い訳)
また希望的な考えもあるので、実践していないものもあります。
テキスト
テキストとは、ユーザーへ見せるテキストすべてが対象です。
例えば、ボタンラベル名、ダイアログメッセージ、説明文などすべてが対象です。
- 他のテキストとトーンオブボイスが揃っているか？
- 使用する言葉の表記揺れはないか？
- コンテキストを踏まえた言葉を使用できているか？
- 説明文は、説明を尽くせているか？
スタイル
更新されたスタイルに対して1行1行丁寧に確認しましょう。
- CSSのプロパティに無駄な定義はないか？
- テキストデータや配列データなどが増減してもデザイン崩れしないか？
- サポートブラウザ・端末で期待通りの見た目になっているか？
- レスポンシブに対応できているか？
- Figma等のデザインデータと比較して、余白設計などが揃っているか？
- デザイントークン外のパラメータは使っていないか？
- 使っている場合は特別な意図があることが明記されているか？
- 苦手なCSSを克服しよう | ジブンノート - silverbirder.github.io のレイアウトの考えを考慮しているか？
インタラクション
ボタンクリックした時やホバーした時など、マイクロなインタラクションすべてに確認しましょう。
- ボタンなどをクリックした場合、必ずわかりやすいフィードバックを返せているか？
- ボタンなどが押せないことを示す場合、なぜ押せないかユーザーに伝えれているか？
- クリック可能な要素をホバーした場合、押せることが伝わるフィードバックを返せているか？
- フォームでバリデーションエラーを表示する場合は、適切な位置とタイミングでユーザーへ伝えれているか？
テスト
プロダクションコードを変更したら、それと対となるテストコードの変更をチェックしましょう。
- 変更したプロダクションコードに対して、それを保証するテストコードがあるか？
- 単体テストであれば、単体テストコードのお作法 | ジブンノート - silverbirder.github.io のテスト作法を考慮しているか？
- 複数画面間で影響したりAPIデータ依存な変更をする場合は、結合テスト・E2Eテストで保証できているか？
- パフォーマンスチューニングなどを行なった場合は、パフォーマンステストコードで保証できているか？
- 見た目の変更を行なった場合は、その見た目を保証するテストコードが書けているか？
- テストケースの文章が、テスト内容を表しているか？
- 複数のパラメータによる複雑な条件の場合、網羅的なテストが書けているか？
終わりに
他にもいろいろあるのですが、メモとして残しておきました。
また後日、清書するかもしれません。
P.S
昔、観点表として POV - Google Drive - docs.google.com というのを書いているのを思い出しました。
こちらはフロントエンドというより、より広いシステム設計をする際に観点として使用していました。
例えば、observabilityやrobustness、fault toleranceなどの観点としてどうなのか議論するために使用します。
意外にも、観点表から気づけることが多くて重宝していました。
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「フロントエンド」の記事
AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht
最近、iframeを使っています。 クライアントサイドで埋め込む想定で、iframeを使おうとしています。 色々と苦労したことがあったので、書いて残しておこうと思います。 レスポンスヘッダー 前提として、ウェブアプリケーションをプロダクショ
紙を積んだイラストをSVGで書こうとしていました。 （当たり前ですが）図形を表現するためには数学の知識が必要で、学生の頃の記憶を思い出したので疲れました。 所感について、諸々書こうと思います。 成果物 実際に完成したのは、以下の画像ができま
2026年02月17日