2020/04/01 プロジェクト往復の地味にいいところ

いくつかのプロジェクトを行ったり来たりしているとちょっといいことがある。頭の切り替えをしやすいプロジェクトの特徴がわかる、ということだ。

重いPRをレビューしたり、重いPRを出すようなレベルで重点的に関われるプロジェクトは、週にせいぜい２つぐらい。とはいえ、戻ってきたらできるだけすぐに結果を出さないといけないし、単発でサクッと対応する、みたいなのはいろんな形で発生する。

そういう中で、あー、あれやるだけなんだけど、と思いつつもなかなか手を出しづらいプロジェクトは、以下のような特徴がある。
・環境を一度止めると手元で再度動かすのに時間がかかる(docker-composeにまとまってないとか)
・とにかく動作確認しづらい。メール送るのに手順があるとか、クラウドのツールを経由しないと動かせないとか
・コードに一貫性がなく、やりたいことが変わるごとにコードリーディングからやり直しになる
・テストがなく、実行してみるまで動いているのか安心感がない

復帰しやすいプロジェクトはその逆。
・コマンド一発ぐらいで開発に復帰できる
・動作確認がしやすい。バリデーションが強かったりシーダーがしっかりしててデータがクラッシュしづらいとかも大事な要素
・コードの書き方に統一感のあるルールがある
・テストがあり、間違ったことをするとコケる
こういう特徴がある。

また、特殊な事例として、「自分がゼロイチを担当したプロジェクト」は圧倒的に復帰しやすい(たとえコードがゴミでも)。
脳みそにルールをロードする必要がなく、自分ならこう書いただろう、自分ならこの程度までしか書けてないだろう、みたいなことがわかるからだ。

総じて、着手しやすく、確認しやすく、影響範囲が読みやすいプロジェクトは復帰しやすいという単純な話だけど、これが習慣化してくると、読みづらいコードや動作確認に難があるプロジェクトはだんだん鼻につくようになってくる。

この嗅覚を使って、コンテキストスイッチの負荷が低いプロジェクトが作れるともう一段レベル上がるのになあ、と思いながら日々やってます。反省が多い……。