開発体験が良いプロジェクトは開発してて楽しい。一方、開発体験が悪いプロジェクトは小さいストレスが溜まっていきあまり気持ちのいいものではないし、生産性も低い。 開発体験を向上させるためには考えなければいけないことも増えるし実装するコストもかかる。 複数人が参加しているプロジェクトであれば開発体験を良くすることに払うコストは簡単に回収できると考えている。 一人が払ったコストを複数人で回収することになるのだから効率が良い。
単純にコストとして換算できないメリットもあるので特に複数人が参加するプロジェクトであれば開発体験を良くするというのは積極的にやるべきだと考えている。
ビルド時間は短くする
どんな言語でもビルドは必要なのでここにかかる時間を短くするのは大事である。
ビルド時間が短ければ試行錯誤できる回数も増えるし、なによりビルド待ちで集中力が途切れてしまうことを防ぐことができる。
ここでのビルド時間はプログラム単体のビルド時間だけではなく、プログラムを起動するまでの時間すべてである。 例えば開発時でもプログラムがコンテナとしてビルドされリモートホスト上で実行するのであればコンテナのビルド時間とレジストリへの push にかかる時間すべてを含む。
開発マシン上での動作をサポートする
特にサーバーサイドのプログラムを開発している場合、そのプログラムの本番環境は Linux になっていることが多いと思う。もしくは BSD 系のOS。
しかしローカルは macOS だったり Windows だったりと本番環境と同じ OS を使っている人は少ないのではないかなと思う。
本番環境に合わせるために VM を用意したりそもそもリモートで開発するという人もよく見かけるが、そもそも開発マシン上での動作をネイティブにサポートしてしまった方が体験が良い。
そのため OS 固有の機能は抽象レイヤーを挟むなどして、プログラム上でのインターフェースは統一する。 例えば Linux では inotify を使っているところを macOS では kqueue を使うために抽象レイヤーを間に挟むという感じである。
開発マシン向けのコードは当然本番環境では動作しないので無駄に感じるかもしれない。また本番環境でのみ起きる問題（抽象レイヤーの問題）が発生するかもしれない。 しかし、これらのデメリットを受け入れて開発マシンでのネイティブ動作をサポートした方が確実に体験は良くなる。
開発用コマンドを用意する
開発時は開発用にセットアップが必要だったりするものだが、これを手順書ではなく開発用コマンドとして実装しておくと楽になる。
環境のセットアップだけではなく開発時に便利に使えるサブコマンドをどんどん実装していくと良い。そうすると実装した本人だけではなくメンバーもその恩恵に預かることができる。
開発用コマンドの理想形としては、リポジトリをチェックアウトしコマンドを1つ実行すると開発環境が立ち上がるくらいまでできると非常に便利である。 プロジェクトに新しく参加した人にも伝えるべきことは
- リポジトリをチェックアウト
- このコマンドを実行したら開発環境が立ち上がるよ
だけで済む。
なるべくメンバーがセットアップなどで悩まないようにできると良い。
開発中、環境の詳細がわからないとデバッグできないということはよくある。それを事前に知っておくために環境を手で構築しておくという考えもあるが、そういう問題に出会ったときに環境を調べれば良い。 別にプロジェクト参加初期の段階でそれについて知っている必要性はない。
開発用コマンドが内部で何をやっているか知る手段を知っていれば後は自分で調べることができる。
IDE でテストを実行できるようにする
IDE はテストを実行するだけではなくその結果をグラフィカルに表示したりなどで色々と支援してくれる。 その支援が使えると実装時に TDD のようなフレームワークを実践しやすくなるしテストをどんどん書いていくことで結果的に生産性が向上する。
そうやって増えたテストは将来的には品質の維持に役立ってくれるだろう。
そのためにはどんなビルドツールを使っていても最低限 IDE でもテストを実行できるようにしておく。
開発体験向上のために
日頃やっている開発体験向上のためのプラクティスについて一部を紹介した。
こういった具体的なプラクティスより一番大事なのがプログラム自体の 優しさ であると思う。 その優しさは実装者がどれくらい様々な状態を考慮できたかとか、利用者側のことを考えることができたかによって生まれると思う。
実装者も次の瞬間には利用者になる。サービスを開発している場合はそのサービスの利用者のことを思い描くだろうが、サービスの利用者だけではなく自分と同じ立場でプロジェクトに参加しているメンバー、さらにはプロジェクトメンバー全体のことを考えてみても良いのではないだろうか。