<aside> ◻️ L I F E

<aside> 📝 2022/12/25 知識系はツェッテルカステンベースで再整理中（✅  再整理完了 ‣ ）

</aside>

• 自身について
• 学び（一般）
• 学び（IT / プログラミング）
• 学び（デザイン / マーケティング）
• ライフログ </aside>

<aside> 💡 目次

</aside>

<aside> 📆 2021/02/03 書いた 2021/06/10 更新した

</aside>

原則：レビューに対する心構え・マインド

• 観点を明確にする
  • 情報設計なのか、デザインなのか、抜け漏れはないかの確認なのか
  • レビュー依頼者が観点を明確にできているわけではない。自分がまず整理してあげる
• マイルドに伝える
  • 険悪な感じになりがちなので注意
  • レビューする人とされる人に上下はない、役割が異なるだけ
• 自分がレビュー依頼するとき（細かな Tips）
  • A案に対してレビューお願いします、だと良いか悪いかの判断になり、
  • A案B案のどちらが良いと思います？だと、どちらかを選ぶレビューになる

デザインレビュー時の観点

• UX 5階層 のどのレイヤーに対するレビューなのか明確にした方が良い

  • 観点がズレていると、一生発散するので注意
  • 依頼者側が観点を分かっていない場合も多いので、コミュニケーションを挟む
    • 「これのレビュー観点ってなんでしたっけ？」
    • 「この時間ってどこまで決まってれば達成でしたっけ？」

  

  https://goodpatch.com/blog/elements-of-ux より引用

• 表層：デザインの原則から外れていないか UI デザインについて

実装レビュー時の観点

• 仕様周りの観点
  • 仕様を満たせているか / 抜け漏れはないか
  • 他の箇所に影響は出ていないか
  • そもそも仕様としておかしなところ（仕様バグ）はないか（改めて）
• コード周りの観点
  • DRY になっているか
  • 責任が適切に分割されているか
  • フレームワークの思想に則っているか

プルリク時のコメント略語

• MUST : 必ず直すべき
• IMO : 自分なら直すけどどう? 緩やかな指摘(In my opinion)
• IMHO : 丁寧なIMO (In my humble opinion)
• nits : 細かい指摘(nitpick)