変数/関数の命名のプロセスと、コメントと、企業文化と、正直・誠実さ

会社の同僚に教えてもらった「命名のプロセス」という記事を読んでみて思ったことを書いてみる。参考にした記事が見たい方は、ページ末尾を参照してください。

ぼくはその記事を読んで「命名プロセスには4つのステージがあって、企業文化とも関連するのではないかな〜」となんとなくおもったのでそれを書きました。ご査収ください。

命名の4つのステージ

Deceive(詐欺る) -> Surrender(降伏する) -> Let it go(ありのままの) -> Solve(解決する)

Deceive(詐欺る)

自然状態。何も考えずにやるとこうなる。

命名を省略したり、ちょっとそれっぽい名前にしてごまかす段階(とりあえず意味もなく getDatatmp などと書く)

Surrender(降伏する)

命名のつけかたがわからないので「わかりませんでした」という意味をこめて、

getThingsICannotUnderstand と書いたり、

コメントで // このgetDataは、こういうことをやっているようだけど、よくわからなかった 等と書く。

または誰かに質問する。

「わからなかった」ということを示すために重要

Let it go(ありのままの)

その機能そのものを表現して、正直な名前をつける

removeNameFromDealAndMakeThisNameLargeCapitalThenReturnTheName(deal)

Solve(解決する):

メソッド分割・変数分割する、正しい名前にする、ファイル分割する、など抽象度をあげていく。あとは勝手にやってくれい。

const dealName = retrieveName(deal)
const emphasizedDealName = upCase(dealName)

解説

概観

直観的には、 Deceive状態(名前が誤魔化されている状態) の方が、 Surrender状態(「わけわからん」と明言されている状態)Let it go状態(機能内容を全部書いちゃってる命名) などの「ヤバそうな名前/ヤバそうな付随コメント」よりも、正しそうに見えると思います。

そのため、わりかし Deceive状態 での命名がはびこってしまっているのかなと思います。

特に Surrender状態 では「あからさまなバカっぽいコード」で、誰でも批判できそうに見えます。

「なんでここがわからなかったのに放置しているんだ」とか「いやいや、ここは常識的に考えてこういう意味でしょ」とか、いくらでも批判できます。ただし、そうしていると必然的に Deceive状態 になるんじゃないかなと思います。人間は、あえて批判されなくてもいい場所で批判されようとはしないはずなので……

また、非英語話者にとって、正確な英語で記述したり正しい意味を読み取ったりするのはとてもむずかしいはずです。日本人同士で日本語で伝え合うのでも難しいのに、あえて英語のプロトコルかますことで、めちゃくちゃ難しいことになっています。

そのため「ここ、よくわからない……」というアピールをお互いがすることはすごく大切だと思います。

4つのステージの各段階での「誠実性」と「正確性」

この4つのステージは、DeceiveからSolveまで、徐々に誠実性と正確性を上げるためにぼくが勝手に命名・定義したものです(なので変なこと言ってたらスマソ)

それぞれが、下記の軸のどこかに位置するようになっていると思います。

• 隠蔽 ⇔ 透明
• うそつき ⇔ 正直
• 不正確 ⇔ 正確

ステージアップの方法

とくに Deceive → Surrender に移行することは、それほど容易ではないと思います。

// ここわからなかった なんてコメントや getDataThatICannotUnderstand() なんてものをバカ正直に書いたら「いやいや……(苦笑い)」という反応をされてしまうかもしれません。

でも、わからなかったのに誤魔化されてなんかそれっぽいコードにされる方がぼくは問題だと思います。そしてその後、明確に名前が表現されていれば別のアプローチも取れたはずのコードが、どんどん意図不明の謎コードになっていきます。

名前がわかっていれば「この名前なのに実装がこれになっているのはバグやん」というのも気づけます。意図不明なコードだという認識が共有できれば、チーム全員に「何かここに意図不明なコードがあって、このへんはマジでヤバい」ということも共有できます。

ぼくは別に // ここマジで意味不明 というコメントを書くことを奨励しているわけではないです。

でも // ここマジで意味不明 と書いてもいいような部分を、コメントを書かないことによって、他の誰もヤバさが認識できず、コードを書いたり変更した本人が「あー、Approveされた……よかった……バレなくて……!」となることの方が問題だとおもっています。なので Deceive(詐欺る) と名付けました。

ステージの意味について

Deceive(詐欺る) が、同僚やパートナーを欺く行為です。ダメ!絶対!

Surreder(降伏する) は、「わからない」と言ってしまう、いわばプログラマにとっては降伏宣言に近いものなのでこう名付けました。

Let it go(ありのままの) は、アナと雪の女王のアレです。ありのままの姿見せるのよ〜おお

Solve(解決する) は、「命名する」という範囲を超えてコードデザインを改善していく段階です。

おまけ: 日本語にする

変数名などを英語にする必然性がなく、UTF-8で書けるプロジェクトなら、いっそ日本語を使用してもいいと思います。

英語圏の人が誰も参画してないのに、カッコつけて英語にすると不幸です。もちろん「どんなときでも日本語にした方がうまくいく!」とは思いませんが、たとえばテストケースだけは日本語で書くとかしても全然問題ないと思います。

すべての命名に英語が絡んでくるので、本当に厄介だと思います。

「わからない」と言う

正直に「自分の知識はこれぐらいです」とか「それはよくわからないです」とか「つまりどういうことですか?よくわからなかったです」とかって言うことは難しいです。

でも、1個の個人の知識と経験は、人類全体から見ればカスでしかないので、わからないことに対して「わからない」と言えることが重要だと思います。

もちろん、調べもしないうちから「わからないわからない」とか言うのはまた別の問題っぽいですが、「わからない」と明言することで、他のメンバーも「あんなしょうもないことを質問してもいいなら自分も質問しよう」とか「あー、そこ自分もわからなかったけどそういうことだったのか」などのように刺激を与えられるような気がしています。

とくにパワーが上になればなるほど、そういった「わからんぞ!!!!!!」という明言が、他の人も「『わからん』って言っていいのか」と思えるようにさせる気がしています。

最終的にそうすることで、企業内の空気や文化もよくなって、心理的安全性も高くなって、HRTにもつながるし、ついでにコードも綺麗になってメンテもしやすく、知識も増えて給料も上がっていろいろハッピーになるんじゃないかと思います(※注意: そうならなかった場合の責任は取りません)

※ 参考にした記事について

この下の記事を参考にしました。

実際にはこの参考にした記事は英語の抄訳なんだけど、個人的には元の英語の記事は長大すぎてちょっと読むのがつらかったので流し読みして、自分の雑な解釈にいろいろ付け加えてまとめてみました。

scrapbox.io

これによれば、命名のプロセスは次の7つのステージに分けられるとありましたが、正直「そんな7段階もやってられるか!」とおもってしまいました。

f:id:haruharu1:20200718163628p:plain

特に「Do the Right Thing」というところに引っかかってしまって、そのまま取り入れられないなと思いました。「Do the Right Thing」より前のステージが「Wrong(間違い)」っぽく見えてしまったからです。

あとは、非英語圏の話者は、命名時に英語を障壁としていると思います。

英語圏の文書は、おしなべて英語のつらみが存在していないかのように作られています。これもなんかもにょりポイントでした。

なのでぼくなりに、勝手にこの7つのステージを4つのステージに分けてみたのがこの記事です。ご査収ください!