あ〜これすごくわかる。自分も何度も経験してる。特に焦ってコード書いてる時とか、「とりあえずこれで動く」みたいなノリで実装した部分を後からレビューで指摘されると、説明が下手になっちゃうんだよね。

印象的だったのは、前の案件で複雑な条件分岐を書いてた時のこと。レビュアーに「ここなんでこの順序なの？」って聞かれて、その時は「あ、単に思いついた順だ」って気づいた。実は業務要件を満たすなら別の順序でもよかったんだけど、自分で納得した理由がなくて説明できなかったんだ。

そこからは意識して変わった。コード書く前に、「なんでこうするのか」を最低限でいいからメモしておくようにした。別に設計書じゃなくて、ただ「パフォーマンスの都合で〜」とか「保守性を考えて〜」みたいな一行でいい。そうするとレビューの時も「あ、そういう理由だったんだ」って説明できるし、自分自身もコード書きながらぶれなくなった。

あとは、実装の意図が複雑だったら、それ自体がコードが複雑すぎるサインかもって気づいた。「説明が難しい＝実装も複雑」ってことが多くて、そういう時は小さく分割し直してみたりする。説明できるってことは、コードもシンプルになってる気がする。