エンジニアの実装解像度の話

このポエムでは、エンジニアの実装解像度についてはなしてみたいと思います。

実装解像度が高いとは？

エンジニアの初心者と上級者を分ける能力差のひとつに、実装解像度があると思います。

たとえば、あるまったく同じ1行のコードを初心者と上級者が書いたとしても、その価値は実は違うんですよ、という話です。

初心者がコードを書くとき、とりあえず動けばいいや的にコードを書きがちで、結果的にコピペや依存の逆転などがよく発生するのに対して、上級者がコードを書くときはあらゆる面から多角的に検討をします（そしてそれは多くの場合、無意識下で高速に行われます）。例えば....

・このコードが入った結果、描画処理やDBに余計な負荷をかけてしまわないか。その結果レスポンスに悪影響は出ることはないか

・既存コードとの整合性を崩さないか。同様の実装をしている既存箇所はないか。多重実装になりそうなら適度に抽象化して切り出せないか。変数や関数の命名はチームのルールや言語のベストプラクティスに沿っているか

・DBからデータを引く場合、欠損値や特殊な文字コードなど、想定していない結果が返ってきた結果エラーが発生しないか。データの内容に依存したエラーは発生しないか

・このコードが入った結果、見えてはいけないデータが見えてしまわないか。WAFを正しく使ってSQLインジェクションなどの代表的な脆弱性を防げているか

・あとからメンテする人やレビュワーのためにコメントを書いたほうがいいか？書く場合、既存コードやチームのルールに照らし合わせてどのような量や詳細度がいいか

・追加したクラスやメソッドは、テストコードを書きやすいような抽象度に保たれているか

・影響範囲が広いと考えられる改修を入れた場合、フィーチャーフラグを用いた限定的リリースなど段階的リリースをチームと相談・検討できないか

・バッチを書く場合、冪等性や突き抜け、並列実行などバッチ実装でトラブルになりがちなポイントを抑えておりそれらに配慮した実装になっているか

・適度な妥協をして実装速度を優先したほうがいいケースか

・仕様変更を伴うコードを書いた場合、法務やCSなど他部署との事前連携は必要か

などなど。まだいっぱいあると思います。

実装解像度が高いとは、このような実装評価軸を経験から（多くの場合失敗を通じて）腹落ちして理解しており、実際のコードに反映できる能力が高いことをさしています。

結果として、1行のコードがアウトプットだとして、それが初心者と上級者で一緒だったとしても（なんならコピペだったとしても）検討考慮されて通過したフィルタの数が違うためコード品質に雲泥の差が発生します。一見同じようなコードでも、見えない品質は違う事態が起こりえるわけです。

フィルタの数を増やす

もうひとつ重要な点として、こういった思考のフィルターはぼーっとしてても増えにくいという点です。必ずしも現場経験年数と比例しないところが面白いところ（だいたい比例しますが）で、結局のところ良いコードとは何かを自分なりに調べて本を読んだり先輩のレビューの意図を汲んで自分なりにカイゼンしていったりといった自助努力がないと成長は止まりがちです。

というわけで、今日も私は触ったことのない言語を調べたり、教科書を読んだり、RailsのPRの議論を眺めたりと色々頑張ってフィルタのネタを増やそうとしております。ネタは尽きず果てしない....先は長いぜ...というポエムでした。