サーバーサイドエンジニアの仕事について考える
最近フロントエンドエンジニアの人と「フロントエンドエンジニアってこういう仕事だよねー」という話をしたので、自分が普段やっているサーバーサイドエンジニアのしごとについて考えたくなった。
完全に主観だし、主語が大きいから「サーバーサイドエンジニアの仕事」ではなく「おれきゅーの仕事」と読み替えてもらったほうが正しいかもしれない。
整合性
フロントエンドの場合デザイナやPM、バックエンドエンジニアの話をいい感じに吸収して使い勝手の良いフロントを提案したりしながらいい感じにしていく人ってイメージで、それに対してサーバーサイドエンジニアはプロダクトの整合性について責任を持つ人ってイメージ。
DBのデータに変なデータが入ったりすると場合によってはプロダクトが完全に破滅するし、軽くてもいろんなユーザーに被害が出る。被害が出なくても将来的にそれが負債になって身動きが取れなくなったりする。そうならないように全力で考える人って考えてる。
整合性の問題はDBだけではなくて、たとえばアプリに対してのAPIのスキーマとかにも出てくる。
アプリから見た場合、APIのバージョンは1つだけかもしれないがサーバーから見ると複数のアプリのバージョンから叩かれることになる。なのでjsonを返している場合、リネームやプロパティの削除が互換性の問題で一切できないと考えたほうが良い。サーバーサイドエンジニアは将来に対しての覚悟とかそういう慎重さを持ったほうが良いのかなって思ってる。
意思決定
仕事をしていると実装案が複数あり、どれか一つを決めないといけないときが出てくる。というか毎回そうなると思うんだけど僕だけだろうか？
大体の場合サーバーサイドではAPIスキーマやDBとはずっと付き合っていくことになるので大体頭を抱えることになる。そういうときの一つの指標として「後戻りしやすい方を選ぶ」というのが良さそう。
例えば「カラムのnot null制約をかけるかどうか」という話であれば、「not null制約を掛けておいたほうがnullableに変更しやすい」という点で選びやすい。これはかなり簡単な例だけどこんな感じに困ったらどちらのほうが「後戻りしやすい？」という問いをすると良さそう。
結局サーバーサイドエンジニアの仕事って何
おれきゅーはこう思って仕事してる
- 将来に備えて決定をする/責任を持つ
- 正しいデータを守る人
