転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
自分のコードをレビューする工程を作って、数週間前に書いたテストを読み返しました。
全部通ります。
間違っているものもありませんでした。
それでも、なぜそう書いたのかが読み取れない箇所が6つ出ました。
3つは、コードのどこにも書かれていませんでした
ひとつ目は、呼び出しを記録する仕組みを使っているのに、その記録を一度も見ていない箇所でした。
記録が要らないなら、普通の関数を渡せば済みます。
当時なぜ記録つきにしたのか、読み取れません。
ふたつ目は、要素があるかどうかの確認が1つ余分に入っている箇所でした。
その前の行で要素を取得できている時点で、存在は確かめられています。
みっつ目が厄介でした。
本来なら確かめるべき動きを、そのテストが確かめていません。
ここだけ性質が違いました。
前の2つは余分ですが、3つ目は足りない可能性があります。
わざと外したのか、書き忘れたのかが、コードからは分かりませんでした。
同じ「理由が書かれていない」でも、片方はコメントを足せば済み、もう片方はテストを足すことになります。
もう3つは、コミットメッセージの中にありました
残りの3つは、調べたら理由が残っていました。
コミットメッセージです。
よく使われている書き方をあえて採らなかった理由や、設定の選び方の理由が、そこに書いてありました。
当時の自分はきちんと考えていて、それを記録もしていたことになります。
ただ、コードを読んでいる人には見えません。
履歴をたどれば出てきますが、テストを読んでいる最中にわざわざたどる人はいないと思います。
自分でもたどりませんでした。
外した判断ほど、痕跡が残りません
6つのうち、はっきり分かったことがあります。
コミットメッセージに残っていた3つは、どれも「採らなかった」判断でした。
やったことより、やらなかったことのほうが、コードには残りません。
書かなかった理由は、書かないかぎりどこにもありません。
コミットメッセージを薄くする話ではありませんでした
最初は、コミットメッセージに書きすぎたのかと思いました。
そうではないと思っています。
厚く書く習慣自体は続けたいです。
問題は、厚く書いたぶんコードのコメントが薄くなっていたことでした。
同じことを2箇所に書く必要はない、とどこかで思っていたようです。
読む人がどちらを見るかは選べません。
コードだけ読む人もいれば、履歴から入る人もいます。
だから、両方に書くほうが正解でした。
似た形がもうひとつありました。
テスト全体の方針が、ファイルのうちの1つにしか書かれていません。
別のファイルから読み始めた人には届かない置き方でした。
通るテストにも、レビューが要りました
緑になっていることは、意図の説明にはなりません。
今回の6つは、どれもコードを変える必要がありませんでした。
足すのは、なぜそうしたかの一文です。
