新卒エンジニアがもらった今週のコードレビュー(1)

いただいたコードレビューを次に活かしたい

これまでコードレビューをいただいた時に、その個別具体的な事象では次に活かせていました。ただ、いただいたレビューを抽象化して理解することで、よりいろんな状況で活かせる気がしたのでまとめてみようと思います。

1.フロントから送られてくる情報は信じるな

自分が書いていたコードは、ある編集画面において、フロントから送られてきたキーを元に処理を変更するというAPIでした。（説明が難しい、、がここが目的ではないので今回は説明は頑張りません、、）
ここでいただいたレビューは、「フロントから送られてきたキーを参照するんじゃなくて、データベースに登録されている情報を取得して確認した方がいい」というものでした。確かにちょっとパソコンに詳しい人なら、inputがdisableになっているのを開発者ツールでけして無理やりデータ送れちゃったりするか、、（そんなこと絶対すんな😡）
今回の件を抽象化して、「フロントは虚言癖持ちなので、それを考慮してAPIを作成する」と学びました、、

2.例外処理はマジで最終手段

自分が書いていたコードは、APIの処理のなかで、ある条件が起こった場合失敗として例外用の処理を行うというものでした。
ここでいただいたレビューは、「例外は基本的に想定外の状況に対処するための仕組みだから、想定している処理の場合は使わない方が良い」というものでした。確かに、何がダメかわかってるのに「自分で考えろ」って言ってくる先生いたし、「意地悪せずに理由教えろよ、、」と思っていたな、、まさか社会人になって自分がユーザーにそんなことしようとしていたなんて、、
このレビューで、「例外処理は、開発者がパターンを考慮できていないが、何かの節に起こる可能性があるもののみ使うもの」ということを学びました、、

3.配列は基本的に根性ない

自分が書いていたコードは、配列のキーがある前提で処理を進めるというものでした。
ここでいただいたレビューは、「ただの配列は、keyが存在することを保証できない」というものでした。
言語によっては、存在しなかった時点で処理が止まったり、nullやundefinedを返したりします。なんて根性のない型なんだ配列、、、ないものは自分で生み出さんかい！！（体育会系）
しかし、できない人をおいていかず気にかけるのもまた体育会系の良さです。根性のない配列には、事前にバリデーションをかけて必ずキーに対する値が存在することを保証したり、nullやundefinedが返されることを考慮したりして優しく接してあげようと思います。
このレビューで、「ただの配列は、キーが存在しないという前提を考慮する」ということを学びました、、
（こういう考え方は防御的プログラミングというらしい、、）

今週のまとめ

型に対しての考え方がばか甘いと気付くことができた。プログラムは、言われたことは勢いよくやってくれるけど、ちょっとわからんことがあったら止まる。将棋で言うと香車みたいだなと思った。もっと気持ちよくプログラムが猪突猛進できるように考慮していきたいなと思った。