良いコード、悪いコードってなんなのか

設計はトレードオフ

私自身よく、このコードはこういう理由でダメだからこう書いた方がいい、とかコードレビューで言いますが、その良し悪しの基準というのはそもそも1つではないです。

多分もっといっぱい分けようと思えば分けられるんでしょうが、このように色々と追求したい要素というのはあり、しかもこれはどう考えても両立できない、ということがほとんどです。

例えば、実行時パフォーマンスだけを追い求めるなら全て密結合にして拡張性は無くなるし、エラーハンドリングも無い方がいいやとなりかねません。
超高度でハイパフォーマンスな最新のテクニックを使ったイケイケなプロジェクトは、それらを使える人材が少なく教育や人員確保に苦労するでしょう。

こんなことは明文化するまでもなく誰でも普段から考えているはずなのですが、良いコードとか悪いコードとかの話になると視野が狭くなることが多いように思います。

絶対的に悪いコードというのは、「さっき挙げたようなどの要素についてもクオリティを落とすことなく、どれかの要素のクオリティを上げる手段」が残っているコード、と言えます。コストを支払わずにクオリティを上げられる方法があるならそれは絶対に採用した方がいいですよね。

Rustはここ数年で言うとかなり注目の言語と言えると思います。私も好きです。Rustの良いところは、コンパイラが頑張ることでできるだけコストを支払うことなく、安全性や実行時パフォーマンスを上げようとしているところで、これが需要とマッチしていたのだと思います。

しかし、Rustは習得難度は高いし、ジェネリックがめちゃくちゃ入れ子になるのも正直読みづらいです。
それでもRustが支持されるのは、支払っているコストが、メリットと比べて重要ではない、もしくは努力によって償却できるものだからです。トレードオフの判断が上手いんですね。

ここまでの話を要約すると

良いコードは重要でない部分でコストを支払い、重要な部分で高いクオリティを発揮する

と言えます。「重要か重要でないか」は場合によるので、当然絶対的に良いコードなんて無いです。コードに限らず、技術選定もそうですね。プログラムに限った話ですらないと思います。

ですから、「良いコード」を書くには、まずはトレードオフの妥当な判断ができること、そして次に妥当な判断を実現できる技術力を身につけることが必要でしょう。同じプロジェクト内でも、レイヤーによって重視するべき要素は変わってきます。これが難しいけど面白いポイントですね。

というわけで、これからは良くないコードを見たときに「クソコード！」と叫ぶ前に、トレードオフの判断が間違っているのか、知識や技術力が不足しているのか、落ち着いて考えましょう。考えてから叫ぶと良いと思います。