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などの観点としてどうなのか議論するために使用します。
意外にも、観点表から気づけることが多くて重宝していました。
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「フロントエンド」の記事
Webmention というのを最近知りました。 名前の通り、Web 上でメンションすることができます。 受信側、送信側、どちらも対応したので感想を残そうと思います。 Webmention ざっくりと Web AサイトにBサイトのリンクをつ
ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。 特に、メジャーアップデートが超助かる。 昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、 さすが ITヲタクくん。 対応してよかったフロー
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi