Webフロントエンドにおける優れた開発者体験を構成する要素たち

素早く変更をトランクに取り入れること。

優れた開発者体験は、一度味わうと二度と忘れられない。
一度上がった生活水準を下げるのが難しいのに似ている。
チームでのフロントエンド開発を念頭に置いている。
規則正しさ＝迷う余地がない。
実装の詳細や、仕様の詳細について考えるための脳のリソースが増える。
レビュー依頼が頻繁にくるが、小さな単位かつ読みやすい構成になっていることをチーム全員知っているので、クイックにレビューすることができる。動作確認も楽。
CIが速いので、PRを小さく多く作っても問題ない。

• 規則正しいディレクトリ構成
  • Container/Presentational
  • Nx Wayな構成（apps/libs）
• 単一目的のコミット粒度&コミットメッセージ
  • Angular Conventional Commit
  • rebaseを活用
  • 「指摘の修正」とか書かない
• 最小単位でのPR粒度
• トランクベース
• Page, Container, Presentationalコンポーネントの明確な役割の分離
  • Page全体のレイアウトの調整
  • asyncパイプを強いて、subscribeを禁じる
  • テストも書きやすい
• UIのテストはTesting Libraryに寄せて、E2Eを極力少なくする
  • 安全性と生産性のバランス
• PR作成時のプレビュー環境デプロイ
  • PRごとに差分をcheckoutしてローカルで動作確認する必要がなくなる
• 高速なCI
  • nx affected
  • E2Eの並列実行
• 必要最小限のPRテンプレート
  • ボイラープレートが少なく、変更の差分に集中できる
• 簡単で、明示的で、ステータスがわかりやすいGitHub to Slack通知
  • ラベル等のPRのステータス変更をトリガーにして、レビュワーにSlack通知
  • Slackの通知チャンネルは必要最小限の情報のみで、誰が作成したのか、誰がレビューする必要があるのか、誰がレビューしているのか、すでにMergeされているのか、がわかりやすい
• デザインシステムが存在する
  • 誰が作っても統一感のあるUI
  • 誰が作ってもアクセシブルなUI
  • PdM、デザイナーとの共通言語