実装、WF作成、デザインで自分が気をつけていること
動機
気をつけていることを一旦整理してみたくなったためです。
リスト化してこのページに対するフィードバックをもらい、改善点を見つけたり、新たな発見を得たりしたいと考えています。
あまり特別なことはしておらず、退屈かもしれません。
バックエンドの実装時
- N+1に気をつける
- 重いAPIがあれば生のクエリまで落として実行計画読む
- 今後ビジネスはどのように発展していきそうで、それに伴ってどの程度のスケールが予想されるか
- (新規にテーブルを作る場合)良く考える
- ここは時間を割くべきと考えている、改修が非常に面倒なため
- (既存のテーブルに対して)現状に対して適切かを考える
- 適切な場合、特に何もしない
- 不適切な場合、改修計画を練り、その計画の実行チャンスを伺う
フロントエンドの実装時
- アプリケーションのユーザーに対して、使いやすいものとなっているか
- ユーザーと開発者の属性が大きく異なっている場合、特に気をつける
- シンプルなUIになっているか
- 定期的にフィードバックを受ける
- 実際のユーザーに聞きに行く
- 実際のユーザーが使っているところを見せてもらう
- フィードバックを受けられない場合、DataDogを見てユーザーの動きを追体験する
- 開発者の想定より長く滞在しているページはないか
- 迷いを生むような階層構造を生み出してしまっていないか
- 不要なCSSを書いていないか
WF作成時
- 不足しているAPIが洗い出せる状態か
- フロントの実装が検討つく状態か
- ビジネスサイドの方に見せて、実装される機能が誤解なく伝わる状態か
- 必要に応じてprototypeも使い、遷移アニメーションも見せる
- コメントや口頭説明で補う
デザイン時
- 余白
- ユーザーが見るであろう画面サイズで変になってないか等
その他気をつけていること
- 似たレビューコメントが発生していないか
- 指摘方法に問題はないか
- そもそもCIに組み込んで、仕組みで解決出来ないか
- 例: unwrapを避けてほしいという指摘が多発していたらclippyに入れる
- ADRの周知は足りているか
- 決めたことはADRに書いて、非同期で作業しているメンバーにも共有する
- エラーが起きたらログ見る
- 隙をついてやりたいことをチームで整理しておく
- 相談や質問をしにくい雰囲気になってしまっていないか
- 組織のコミットルールに合わせる