先日、上司から「コーディングする前に何をどのくらい考えていますか？」と聞かれて エンジニア歴2年半のくせにタジタジしてしまったので改めてコーディングする前に何を考えるべきか 考え直してみたいと思います。
「その機能は本当に必要？」
真にプロとはどういうことだろうか......と考えてたところこんなツイートを見つけました。
僕が思うプロっていうのは「この壁に窓つけたいんだけど」っていうお客さんに対して「できるけど、西日が差し込んで使い勝手が悪いし、隣の土地には家がすぐに家が建って埋まっちゃうことになるからやめときな」って返すことであって、後先考えずに「ハイではこれがお見積もりです」ということではない
— ハイパーむとう (@masa_edw) 2012年5月31日
私の考えるプロとはまさにこのツイートのような提案できるエンジニアであることです。
- 本当にその機能がないと実現できないか
- その機能がユーザ体験が向上するのか（既存実装と齟齬がないかなど）
ただ作るのではなく、本当にそれが必要であるかを自分なりに考えて もしもっと良い案があれば提案できるようになるべきと思います。
「その機能のエッジケースってなんだっけ?」
私が実際にしてしまったミスとして、実装を進めながら考えいると「あっ、このケースに対応しようとするとなると結構変えなきゃいけない！！」なんてことがたまにあります。 要件はあくまで要件であって、細かい仕様からはエンジニアでしっかり精査すべきです。
例えば、顧客選択のフォームが選ばれたら、その顧客に紐づく支社だけが選択できるようにしたいとします。
この場合考えたいのは、「もし支社から選択された場合は、顧客は自動入力されるべきか？」 「選択されている支社に対して紐づかない顧客が選ばれたら支社のフォームはどうしようか？」 などなどさまざまなパターンが考えられます。 実装する前にこうしたエッジケースは洗い出しておいた方が良さそうです。
(このときに状態と境界も意識できるといいかも)
「意識すべきことを減らす」
コードを書く前（書いている最中）に考えておきたいことは、 意識すべきことを減らすということです。
例えば、「Hello, World」と出力するプログラムに日本語対応をしてほしいという要望があります。 そうなると、ifで条件分岐が発生します。さらに中国語、スペイン語....と増えていけば意識すべきことが増えていきます。
状態の種類が増えると、 意識を向けなくてはいけないものが指数関数的に増えていきます。 それはまさにバグのもとです。
既存実装を見ながら、 今回の機能に必要最低限な状態だけを用意するようにして実装を進めていくべきです。
参考になった記事
この辺の記事がとても参考になりました tech.tabechoku.com
