バックエンド開発者 · 業務ごと

エンドポイントと、そのあいだの配管

仕様がはっきりしていて、学習の素材に大量に含まれていて、走らせれば確かめられる——どの業務であれ生成に向いた強い筋書きにする、同じ三つの性質である。しかもこれは、外から見たときのバックエンドの仕事のかなりの部分でもある。

エンドポイントを生成することは、それが存在すべきかを決めることでも、何を保証しなければならないかを決めることでも、二度呼ばれたときに何が起きるかを決めることでもない。この仕事で高くついていたのは、打鍵ではなかった。

同時に物事が起きても正しさを保つ

この種の不具合はテストに現れず、何か月も現れないことも多い。それを考えるには、ほかに何が走っているのか、途中で落ちたとき何が残るのかについての模型を頭に保つことが要る。そして正しい答えは、目の前のコードではなく、事業が交わした保証に依る。

仕事の性質についての判断であって、測って出したものではない。障害が「生成された並行処理のコード」に起因すると公に言われることはまずないが、その沈黙は、それが起きていないことの証拠にはならない——原因をそこまで具体的に名指しする事後レビューは、どんな会社でも珍しい。

データの模型と、使われながらのその変更

初期のスキーマの判断は、何年も経ってから、いまのコードからはどの道具にも見えない形で高くつく。費用はすでにデータのなかに書き込まれてしまったものに宿っているからである。移行はまた実務上取り返しがつかず、それは、助けられるのではなく誰かが責任を負わなければならない部類に入る。

いまや道具が移行の手順を日常的に起草していることについては、何も言っていない——実際にそうしている。ここでの主張は、誰が打つかではなく、誰が決め、誰が答えるかについてである。

誰が何を見てよいか

生成は、述べられた要求に向けて最適化する。そして認可の不具合とは、まさに誰も述べなかった場合のことである。ここはまた、自信たっぷりでもっともらしい誤答が最も危険な領域でもある。誰かがそれを突くまで、正しい答えとまったく同じに見えるからである。

これは測定ではなく、問題そのものの構造に乗っている。決着させるのは、同じコードベースのなかで「生成されたコード」と「手で書かれたコード」を分けて欠陥を数えた研究である。規制のかかった環境では、ここに人の署名がもともと要求されている——効いているのは難しさそのものより、その要求のほうかもしれない。

いくらかかり、どれだけ速いか

病んだ問い合わせを見つけ、索引を提案することについて、道具は本当に強い。弱いのは取捨のほうである——速さのために金を使うことは事業上の判断であり、どの要求が大事かを知るには、その製品が何のためにあるかを知っていることが要る。

これが実務でどれだけ道具主導になっているかは、ここでは何も測っていない。そして答えは、観測に予算のあるチームとないチームとで、まったく違う。

呼び出しに起こされる人であること

見立ての段はますます助けられており、それは本当に効く。判断のほうはそうではない。サービスを戻すために既知の損失を受け入れると選ぶことは、誰かが引き受けなければならない結果を伴う判断であり、しかも設計からして情報が欠けたまま下される。

これは、オンコールの負担が重くなっているのか軽くなっているのかについては何も言っていない——それこそ大半のエンジニアが本当に気にしている問いであり、そして誰も公表しない数字である。