お前の責任でコードを書け
◆ 目次
プログラミング言語やフレームワークにおいて、事前に決められているコードを書く上での指針がある。
例えば、Rustにおける「所有権の問題を回避するために無闇にcloneするのを避けるべき」、Go言語における「変数名を短くするべき」が挙げられる。これについて、盲目的に従うことが良いことだと言わんばかりに、厳密にそれを守ろうとして悩むことに異を唱えたい。一応、読む上での注意点を下部に記載している。
以下では、「良しとされていること」を「ルール」と短縮する。実際はルールというほどの強制力はなく、ただのガイドラインだったりするが、盲目的に従われることが多いことから「ルール」と呼ぶ。
前述のRustの例だと、無闇にcloneするとどういうことが起きるのか、変数名が長くなるとどう良くないのかなど、ルールに従うことのメリットとデメリットを理解していれば、そのルールに従わなくてもよい場合、従わないほうが良い場合があることはわかるはずだ。もしルールに従うことに迷いが生じているのであれば、それはルールによってもたらされる便益を本当は理解していないのだ。理解していないし理解しようともしないから、ルールに疑問は感じるけどそう決まっているから従っておこう仕方ないと考えてしまう。
一方で、ルールのありがたみを理解し、そのうえでルールに従わない方が良いと判断したのであれば、自らの責任でルールを破ってよいのだ。成果物をツール（言語）に左右されるのではなく、お前が舵を取れ。
実際に私はRustを書くとき、cloneによるメモリ使用量の増加やメモリ効率の悪化より、structにライフタイムパラメータがつくことによる設計の複雑化のほうが許容できないときなど、トレードオフを理解し、状況を加味した上でcloneを使用している。
ルールを破ってプログラムが破綻したとしても自分が責任をとって泣く泣く修正してもいいし、作り直しても良い。もちろん後悔することになるとは限らず、メリットとデメリットを理解した上で意思決定をしたのであれば、ルールを破ったとしても良い結果が得られることもあるだろう。いずれの場合も、自分が納得できる結果が得られるはずだ。
チーム開発の場合は個人の責任でルールを破るべきではないだろと考えるかもしれない。たしかにそういう面もあるが、チーム開発の場合でも、ルールが合理的でなかったり、状況に合わなかったりしたときはルールを破ることも視野に入れるべきだ。もちろん、ルールを破ろうと先陣を切る個人がチームに対して提案し、説得できるだけの材料を用意しなければならないので、個人開発よりはルールを破る負荷は高まるだろう。しかし、前述の通り、そもそもトレードオフが分かっているのであればチームを説得するための材料はすでに揃っているはずだ。あとは勇気さえあればチーム開発でもルールを破れるだろう。
まとめ
- お前の責任でコードを書け。
- ルールに疑問を持ったなら、ルール通りにできない自分を内省するのもいいが、自分はルールに従うべき状況にあるかどうかを判断する知識や責任能力がないことを内省しろ。
注意
- 各言語や環境ごとにで良しとされていることが間違っているという主張ではないし、それに従うのをやめろと言っているわけでもない。
- ルールを破るのが正義と言っているわけでもない。
- そもそもそんなルールはない、受け取り側がルールの解釈を誤っているとか思うかもしれないがそんな話もしていない。
- 破った場合にセキュリティリスクが発生するルールなど、破ってはならないルールが存在することを否定していない。ただ、前述の通りデメリットを理解していればルールに従う判断は自ずとできるはずだ。
- プログラミング言語の話を例に出したが、この話は自分で決めたコーディング規約や、プログラミングとは関係ない方法論などにも同じことが言える
参考
- kbwo on X: "実際、いつdropされるのかが意識できていればcloneを許容できる場合も多いのでそこまで神経質にならなくてもいいんじゃないかと思っている" / X https://x.com/__kbwo/status/1829797012738621734
- mattn on X: "Go で変数名を短くできるのは変数のスコープが狭い場合のみです。例えば for の中身だけ使うループ変数 i とか、関数呼び出し結果に対してすぐ下で処理を書くなど。それ意外は長い名前を付けるべきだと思います。" / X https://x.com/mattn_jp/status/1829855996921164121