新人の人でも最近は実装それなりにできるという人が増えたような気がする。
しかし、学生のときよりも考慮するところや必要な力が多くなり、そこでつまずくのはいまだに結構あるんじゃないだろうか。今回はそういう点についてまとめる。
ざっくりまとめると、プロダクト・コードの品質、設計、コード読解力だ。
目次
バグを出せる、異常系を考慮できるか
プライベートや学生の授業レベルだとそこまで異常系を考えることがないと思う。
仕様によるが、製品レベルのコードだと絶対に異常系の考慮が必要なところだ。ここが一番学生時代と違うところではないだろうか。
もしオフラインだったらどうするか、もしこのエラーコードが返却されたらどうするか、ユーザーがこの操作したらどうするかのあらゆるパターンをすぐ想定できるようにできると良いと思う。
この観点は実装だけでなく試験者のときでも重要だと思う。
同じこと何度もやるより、オフラインでこの操作やるとどうだろう？色々操作して内部状態が変わってそうな時にこの操作やるとどうだろう？みたいな観点でやっていく方がバグを出しやすいのではないだろうか。
コンポーネント分割・再利用性・依存関係の妥当性
プライベートで作るちょっとしたアプリなら正直あまり設計のこと考えなくてもうまくいくのではないだろうか。
業務ではたいていチーム開発なため、設計をある程度ちゃんと考えてないとコンフリクト祭りになったり、仕様変更の修正が大変になる。
いきなり実装ではなく、クラスやファイル構成がこれでいいか実装前にレビューを受けるのもいいと思う。
このコンポーネントは再利用できる、どう切り離せば再利用しやすいか、ここを今後修正するとしたらどうすれば影響範囲を狭めることができるか、こういうところを考えることができると業務でしっかり実装・設計できるといえるのではないだろうか。
それらの設計の原則としてSOLID原則やデザインパターンがあるので、それも学んでおくとよいと思う。
変数・関数の命名
これは結構ありがちな気がする。
業務だとたいていチーム開発のため、他の人に自分のコードを読まれる。テキトーな命名だと非常に処理が追いづらい。また、関数名が実際の処理と違う内容だったりするとかなり混乱する。
読む相手に分かるように、省略しすぎない役割を示した命名にするよう注意が必要。
エラーメッセージを読む力
英語のエラーメッセージを読んでどういうエラーかが分かること、これが意外とできない人がいる。英語だからと無視せず読む、当然だけど大事。
エラーをコピペして調べて書いてある通りに直したらできましたではなく、エラーメッセージの内容をしっかり読んでほしい。
視野・視座を変えてコードを解析できる力
なぜか怪しいと思った箇所を永遠に凝視して静的に解決しようとしている人がいることがある。静的でも視野を変えてみるなり、動かしながら視野・視座を変えてコードを解析するなりできる力がほしい。
この箇所のコードにエラーがありそうだ！でもここは問題なさそう、じゃあここを呼んでる関数か、ここにテストコード書くかログを仕込んで関数がちゃんと動いてるか見てみよう、みたいな感じで視野・視座を適宜変えてコードを解析して不具合を解析できる力も必要ではないだろうか。
抽象・具体を行き来できるか
プロダクトのコードを追っていくとき、抽象・具体を行き来できる力が欠如しているとなかなかコードを読むのが進まないのではないだろうか。視野・視座を変えることと近い意味合いだが。
個人的に抽象・具体という概念はプログラミングで非常に重要な要素の一つだと思う。
このページはここにページング処理があってここでデータを取得して描画しているのか、どういうクエリでデータを取得しているんだろう、ページングはどういう処理だろうなど、抽象から具体にコードを追える力を身につけておきたい。
また、この処理はページ指定してデータをDBから取得するのか、その処理はページング処理から呼び出されているな、このページング処理はタスク一覧ページの一部なのか、みたいに具体から抽象にコードを追える力も身に着けるべきだと思う。