刺激的な学びがとてもある ~ 命名に妥協するな ~

「いい設計ができる人は、「本当の名前」を探し出す努力をする。」

と、アーキテクトから自分の足りないところとして指摘をいただいた。とても胸に刺さった。めんどくさがらず、横着せず、妥協しない。意図が明確にある命名にしなければいけない。命名が正しくないといい設計は絶対にできないと言われた。

自分も実態に伴っていない変数名を見た時はリネームPRをすぐさま出す。結構ドヤ顔できる。実態と違う命名がされているとノイズになってコードリーディングに負荷がかかる。とはいえ、そんな僕でもまだコードに明確な意図を伝えられないことが多い。

例えば、「XXXが1つもない時はエラーにする」というエラー型に対し、Error.MissingXXX という命名をつけた。「XXXがないエラー」という意味を込めて命名した。「Missingって単語の意味、調べました？」と咄嗟に返ってき、その後見事に論破された。多分今回は「XXXNotFound」とかが適切かな。こう見れば当たり前だけど、いざ業務が立て込んでる時に命名するとあまり自分の本質的なミスに気づかないことが多い。

Missingは「欠けている」という意味を持つため、1つもなかったらいけない、存在しなければいけないものがない、という意味とは別物。

このような指摘を、アーキテクトのもとで開発してからものすごい喰らう。もっとたくさんこれに似たエピソードが今日だけで4個ある。今までもらったことのない指摘でちょっと落ち込む。でも、技術力が高い人は総じて、「これって意味違くない？変数名が意味を成してないからいろんな人が誤解して変なコードが増殖する」と呟いているのをよく耳にする。

それぞれの変数の本質を見極め、それを忠実に英単語にする。自分にはこの感覚が足りていない。変数名にこだわりが全くないわけではないが、明確に100%一致した、本質を見抜いた命名を意識できているわけでもない。

自分に今足りないのはこれだ。これがないと、絶対に自分が目指す設計能力は持てない。

めちゃくちゃ雑に書いてるけど、一旦メモ

人は独自に翻訳をする。それは誤解をするとも言えること。だから、誤解され続けながらコードを書かれると、実態との乖離が進み、スパゲッティカードにならざるを得ない。

将来の開発者にも影響を与えるし、チーム開発である以上、すぐそこの人間にも影響する。だから、命名は意思と意図がはっきりないといけないもの。実装者は自分の実装に責任を持つ、つまり、自分ごととして、人に何を言われても曲げない意思が必要。曲げる必要もないほどの明確な意図があれば、それは多分人に伝わる。ただ、少しでも曖昧性があるなら、それは誰かにとってはわからない。

というのを豚山に並びながら書いている。