なぜ、どのように、いつ読みやすいコードを書くか

もし開発チームの調査をしたら、ほとんどの開発者が"読みやすいコードが欲しい"と言うだろう。開発チームは機能性より読みやすさを好ましいと思っているかもしれない。しかし、読みやすさを定義しようとすると、意見が割れる。この話はExplore DDD 2018でのLaura Savino氏のプレゼンの前提になっている。氏はなぜ読みやすいコードが良いのか、読みやすさとはどういうことなのか、他の考慮点よりも読みやすさが絶対的に優先度が高い場合はどんな場合か、について話をした。

Savino氏は、元は小学校でフランス語を教える教員であり、その後、iOSの開発者として、また、アドバイザーとして働いている。それゆえ、話し言葉とプログラミング言語について、ありふれた比較よりも、深い洞察が提供できる。新しい言語を学ぶ開発者は"Hello, world!"を出力する単純なアプリを作る。同じように、フランス語やスペイン語、ドイツ語を学習する場合、始めは"Bonjour"、"Hola"、"Guten-tag"を覚えることから始める。

プログラマが"Hello, world!"から素早く遠ざかるように、話し言葉の学習も次のレベルに移動する。例えば、あなたがフランス語のクラスでクラスメートを、授業が終わったらコーヒーを飲みに行かないか(Voulez-vous prendre un café avec moi après les cours?)と誘ったとして、ネガティブな回答(Désolé, je ne peux pas prendre de café après les cours)が得られた場合、この会話を聞いている人はこんなつまらない会話は聞いたこともない、と思うかもしれないが、あなた自身は有頂天になるだろう。あなたは発言をし、その発言は正しく理解され、適切な返答があり、あなたはその返答を理解できた。データをiOSのアプリに表示するのに似ている。魅力的なやり取りではない。しかし、これが初めてできたとき多少なりとも興奮するはずだ。

そして、話し言葉の学習をさらに進めると文法について考えることになる。目的は、互いに理解し合うことを超え、ニュアンスやデリカシーの波長が合うようになることだ。ここから、人間の言葉に対する類推の分解が始まる。少なくともより深い分析が必要だ。

コードレビューでは、ある人が"このコードを理解するのは大変だ"と言い、そのコードを書いたのかもしれない別の人が、"でもこの方が読みやすい"と反論する、というようなやり取りがあることは一般的ではない。氏はこの点を"読みやすさには読み手が必要だ"ということの説明に使う。開発者にとって読みやすさを複雑にしているのは、書いたものにふたつの異なる読み手がいることだ。つまり、他の開発者とコンピュータだ。コンピュータは声が大きく自説を曲げず、理解ができなかったらすぐに教えてくれる。私たちは自然とコンピュータに合わせる。このことを知っているので、私たちはコードを人間が読めるコメントで囲むことで埋め合わせをする。しかし、Savino氏によれば、"読みやすいコードへの道はコメントでは表現できない"。

Savino氏はテキストやコードを読み解くことと流暢に読むことの違いを明確にする。氏はE. E. Cummingsの詩"when serpents bargain for the right to squirm"を美しくも複雑な一節として引用し、本当の意味を理解するにはいくつもの道があることを示した。コードを読むとき慣れていない書き方に出会うと、これと同じレベルの解読が発生する。ひとつ読んだら次へ、そしてその次へと読んでいくと当初の目的がわからなくなってしまうような状態になる。深く理解することには喜びが伴うが、"知的な詩はソフトウェアを生み出さない"と、氏は警告している。

逆に言えば、流暢に読むことは素早く正確に理解することであり、ワーキングメモリを酷使しない。読者としての長年の経験によって、さっと読むだけで理解できる。Savino氏はしっかりと記述されたコードなら同じことが言える、と考えている。簡単に読めるコードなら、何かおかしいときには脳の一部が反応するので、レビューがより効率的になる。

なぜ読みやすいコードが重要なのかを明らかにして、氏はどのようにコードを読みやすくするかを説明する。不慣れな話者とコミュニケーションするにはスラングを避け明瞭に発音するのが重要だ。コードでは、releaseTheHounds()と命名するよりbeginApp()とした方がいいということだ。また、関数をチェーンにするより、変数と結果を明確に書いた方がいい。

また、氏は人間の直感的なパターンマッチング能力についても説明し、同じ動きをするものが同じに見えることを説明した。抽象的なレベルでは、コードの全体的な構造を把握するために"squint test"を使い、何か目立った点があるかどうかを確認する。より低位なレベルでは、同じようなかたちをしている文字やシンボルの利用を避ける。例えば、!、I、lや1だ。これらの文字はパターンマッチングの能力を害する。何か区別できる部分があるなら、それを他のものと区別している性質に則った名前をつける。

書き手に対する最高のアドバイスは"読み手を知れ"、ということだ。読み手がコードを読むなら、さらに一歩進んで読み手を信じる必要がある。誰かにコードが不明瞭だと言われたら、相手を信じて、どのような情報が足りずに読みにくくなっているか尋ねてみる。混乱をデータとして扱い、コードの読みやすさを改善するのに活用する。

最後に氏は、いつ読みやすいコードがもっとも重要になるのかについて話をした。そのコードがより重要になれば、そのコードはより読みやすい必要がある。氏はNASAのジェット推進研究所のコーディングガイドラインから"ミッションクリティカルなコードは単に間違いがないだけでなく、細部まで正しくなければならない"という言葉を引用している。人間のコミュニケーションも関わるような地に足のついたシナリオは非常階段を示すサイネージであり、火事のときに余計な努力なしで読み解ける必要がある。

いつどんな場合に読みやすいコードが必要になるかチームで話し合うといいだろう。チームの全員が流暢に読めるようになるのがゴールだ。"解読を少なくして、もっと想像しよう。"と氏は言い、講演を終えた。