実装、WF作成、デザインで自分が気をつけていること

Blog Image

動機

気をつけていることを一旦整理してみたくなったためです。
リスト化してこのページに対するフィードバックをもらい、改善点を見つけたり、新たな発見を得たりしたいと考えています。
あまり特別なことはしておらず、退屈かもしれません。

バックエンドの実装時

  • N+1に気をつける
  • 重いAPIがあれば生のクエリまで落として実行計画読む
  • 今後ビジネスはどのように発展していきそうで、それに伴ってどの程度のスケールが予想されるか
  • (新規にテーブルを作る場合)良く考える
    • ここは時間を割くべきと考えている、改修が非常に面倒なため
  • (既存のテーブルに対して)現状に対して適切かを考える
    • 適切な場合、特に何もしない
    • 不適切な場合、改修計画を練り、その計画の実行チャンスを伺う

フロントエンドの実装時

  • アプリケーションのユーザーに対して、使いやすいものとなっているか
    • ユーザーと開発者の属性が大きく異なっている場合、特に気をつける
  • シンプルなUIになっているか
  • 定期的にフィードバックを受ける
    • 実際のユーザーに聞きに行く
    • 実際のユーザーが使っているところを見せてもらう
  • フィードバックを受けられない場合、DataDogを見てユーザーの動きを追体験する
    • 開発者の想定より長く滞在しているページはないか
    • 迷いを生むような階層構造を生み出してしまっていないか
  • 不要なCSSを書いていないか

WF作成時

  • 不足しているAPIが洗い出せる状態か
  • フロントの実装が検討つく状態か
  • ビジネスサイドの方に見せて、実装される機能が誤解なく伝わる状態か
    • 必要に応じてprototypeも使い、遷移アニメーションも見せる
    • コメントや口頭説明で補う

デザイン時

  • 余白
    • ユーザーが見るであろう画面サイズで変になってないか等

その他気をつけていること

  • 似たレビューコメントが発生していないか
    • 指摘方法に問題はないか
    • そもそもCIに組み込んで、仕組みで解決出来ないか
      • 例: unwrapを避けてほしいという指摘が多発していたらclippyに入れる
    • ADRの周知は足りているか
      • Slackに定期で流すようにする
  • 決めたことはADRに書いて、非同期で作業しているメンバーにも共有する
  • エラーが起きたらログ見る
  • 隙をついてやりたいことをチームで整理しておく
  • 相談や質問をしにくい雰囲気になってしまっていないか
  • 組織のコミットルールに合わせる