こんにちは、システムチームのKです。
先週、今週と一人のチームメンバーの対応に
時間を割くことが多かったのですが、
なぜそんなに時間がかかったかというと、
修正→コードレビュー・テスト→再修正→コードレビュー・テスト→…
このループが何度も発生していたからです。
「直しました」と提出してきても、
直っていない、他の箇所でまだエラーが出ている。
という状態ですね。
6月からシステムチームに新しいメンバーが入社しました。
未経験の彼も、今後同じ状態に陥る可能性がありますので、
この機会にブログ化しようと思います。
「なぜ」エラーが起こったのかを明確にしないまま修正
問題の原因はこれに尽きます。
何度も修正が発生していたメンバーが提出してきた内容を見て
「この修正コードはなぜこのように書いたのか」を聞くと
少し沈黙の後、「うーん」「えっと」「これで直ったので…」
という処理の話にならない回答が返ってきます。
この回答が返ってくるときは、
「エラーの原因がわかっていない」ときです。
コードレビューする側からすると、
「あ、これ原因わかっていないな」というのは、
コードを見ればだいたいわかります。
例えばCSSの修正なら
・absoluteやtransformを使って要素の位置を調整している
・widthやheight、margin、paddingに使われている値が半端。例）17px,26px
・%を使っている
・マイナーなプロパティを使っている
・セレクタ指定の粒度が浅い
プログラムの修正なら
・処理を丸ごとコピーしてきて、一部分だけ変更している。
・指示した修正以外の差分が無い
このあたりの内容がコードに出ている場合は、
エラーの原因がわかっていないと考えています。
そう判断する理由は、複数の画面や環境で
チェックしていないことがわかるコードだからです。
今自分のモニタに映っている画面上で
動いた、整ったからOKとしている。
これではエラーを修正したとはいえません。
原因がわからないとエラーは「根本」から直せない
コードレビューしたとき、
前述のようなコードが存在する場合は、その時点で
「なぜこのように書いたのか」という質問とともに、返すようにしています。
論理的に説明できるなら良し。
むしろそこまでちゃんと考えられるようになっているので、
成長を褒める対象です。
ですが、説明できない場合は、影響範囲がわかっていないので
絶対にそのコードが原因でまた別のエラーが出ます。
リリースしてから、エラーが出ることは絶対にやってはいけないし、
開発途中でも、修正→レビューの回数が増えます。
だから、エラーが出た原因を理解して、
一度で修正しきることが大切です。
どうやって原因を明確にするか
本記事は、未経験から入社2年目のプログラマと、
6月から入社の新入社員に向けて書いている前提なので、
自分の引き出しだけで原因を明確にできないこともあると思います。
そういう時にどうすればいいかというと、
・エラーが出ない状態から出る状態を再現する
エラーが既に出ている状態から、いろいろ特定しようとしても推測の域を出ません。
エラーが出ていない通常時から、自分でエラーを出すことで、
「何をどうすることでエラーが出る」かを把握できます。
・Webで調べる
基本的に調べて解決しないエラーはほぼ無いと考えています。
調べても原因がわからなくて、、、という場合は調べ方の問題です。
エラー文が出ている場合は、英字のエラー文そのままで調べます。
変に事象を日本語に置き換えて「○○ 動かない」のような検索をすると、
候補は出てくるでしょうが、原因が異なるものも出てきます。
エラー文そのままで調べた場合、
検索結果はほとんど英語サイトになりますが、それに拒否反応を出さないこと。
英語サイトの方が、
情報量は圧倒的に豊富ですし、新しい情報もまずは英語で公開されます。
内容が読めないのなら翻訳ツールにつっこみましょう。
上司に相談するという方法もありますが、
上司側も相談につきっきりにはなれないですし、
なにより、学校みたいな状態になるので、
基本的に自分で調べて、解決して、知識として蓄え、次回からは同じエラーを出さない。
ということが大切だと思います。
