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

動機

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

バックエンドの実装時

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

フロントエンドの実装時

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

WF作成時

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

デザイン時

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

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

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