1か月前の自分へ。
いいコードって何ですか？
技術力の高さって何ですか？
ほぼ完璧なプログラムがあります。
とある、とても複雑な業務の要件とビジネスロジックを完全に満たし、実装します。
ただし、100億個の静的フィールドがあります。それらは、すべて参照です。
起動しただけで、80GBのメモリを占有します。
これはいいコードですか？
ほぼ完璧なプログラムがあります。
とある、NP-hard問題の非常に精度のいい近似解を出力します。
ただし、すべてのメソッド呼び出しがリフレクションです。
メソッドの中身は、10命令程度ですが、解を得るのに100万回呼び出す必要があります。
これはいいコードですか？
ほぼ完璧なプログラムがあります。
未知の、地球からの電波すら届かない深宇宙へ向かう探査機を完全に制御します。
ただし、サイクロマティック複雑度は1億で、クラス結合は1万、保守容易性指数は0です。
もはや誰も触ることができませんが、今のところ完璧に動作します。
これはいいコードですか？
あなたと、もう一人が同じ目的のプログラムを書きました。
彼のプログラムは、10msを要しました。
あなたのプログラムは、1msで済みました。
あなたは、彼より技術力が高いですか？
彼のプログラムは、10MBのメモリアロケーションを要しました。
あなたのプログラムは、1MBで済みました。
あなたは、彼より技術力が高いですか？
彼のプログラムは、100行でした。
あなたのプログラムは、10行でした。
あなたは、彼より技術力が高いですか？
彼のプログラムには、10個の public の静的関数がありました。
あなたのプログラムは、1個の public の仮想関数のみでした。
あなたは、彼より技術力が高いですか？
彼のプログラムは、不正な入力を与えると終了コード -1 を返して終了しました。
あなたのプログラムは、入力の誤りを具体的に指摘する丁寧なエラーメッセージを返しました。
あなたは、彼より技術力が高いですか？
彼のプログラムは、ネット上のコードをコピペして繋いだような、たどたどしいコードでした。
あなたのプログラムは、標準ライブラリのソースコードと見分けがつかないほどでした。
あなたは、彼より技術力が高いですか？
開発者にできるだけ多くの選択肢を提供することを是とする言語を使っていても
開発者にできるだけ単一の書き方を迫ることを是とする言語を使っていても
同じ目的のために、二者択一、あるいはそれ以上の書き方が存在することもあるでしょう。
そのとき、きっとあなたは今までの知識、経験、読んだコード、書いたコード、成功、失敗、反省、そして直感から
意識的か、あるいは無意識的にどちらかを選択しています。
あるいは、誰かにアドバイスをするとき、他の人のコードをレビューするとき、あるいはされるときにも、
きっとその「選択エンジン」を活用している。
もし、あなたがその言語やフレームワークについて、「技術力が高い」と言えるほどの技術力があるならば
その技術力を培ってきたcontextにおいて、その「選択エンジン」はおよそ正しいに違いありません。
そして、その「選択エンジン」はこのポエムの冒頭に、強い嫌悪感のシグナルを送ったでしょう
そんなコードはおかしい、あってはならない、修正されるべきだと。
でも、たとえ100億個の静的フィールドを持っていても、それが誰かにとって大きな価値を持つならば
数百GBのメモリを持つインスタンスを用意するのは難しい話ではない。
それは単に静的フィールドであって、メモリリークでも、リクエストごとのヒープアロケーションでもない。
どれだけ直感に反するとしても、実用上の問題は大してない。
もちろん、他のすべての条件を等しくして、100億個の静的フィールドがない実装が選択できるならば
それはおそらく、正義といっていい。
ただ、100億個の静的フィールドがない実装を選択するために、狂ったインスタンスの料金よりも工数を要するなら、
必要としているユーザーに届くのが遅くなるなら、ユーザー体験を損なうなら、その狂った実装を受け入れる方がいい。
NP-hard問題の近似解が得られるなら、すべての関数呼び出しがリフレクションでも意義がある。
どうせ二度とメンテナンスできない宇宙へ旅立つプログラムなら、どんなに保守性が悪くても構わない。
とても極端で非現実的な例を持ってきてしまって申し訳なかった。
ただ、
class Code
{
public string Content { get; set; }
public string Author { get; set; }
}
に IComparable<Code> 実装を入れたいなら、WritenContext か TargetPloblem みたいなフィールドを追加する必要があることに気づいて欲しい。
今のコーディングにおける公理系ともいえる「選択エンジン」が、それを培ったコンテキストに依存していることに気づいて欲しい。
たとえプログラミング界の発展が、今日の情報社会が、コピペ可能で import 可能で fork 可能な、コードの再利用可能性に依存していたとしても
そんな再利用可能なソースコードすら、"AS IS" で "WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT"に提供されている。
すべての目的、ユースケースに適合することは免責される、つまり、あなたの「責務」ではない。
コードは、単にあるべき課題に、現在の社会の必要性のために存在するべきであって、そのもとに比較される。
常に早いコードが正義ではない。常にメモリアロケーションが少ないコードが正義ではない。常にコード行が少ないのが正義でない。
それらが必要とされていないならば、何のユーザー価値もユーザー体験ももたらさないのならば、もはやそれは開発者の自己満足に過ぎない。
その「選択エンジン」を、直感をどう客観的に説明するのだろうか。直感に命を賭けられるのは一生に一度だけである。
どんなに抽象化され、汎用性の高い関数も、1通りの呼ばれ方しかしないなら意味がない。
どんなに丁寧なエラーメッセージを返そうが、そもそもエラーが滅多に起きないなら意味がない。
その実現に、少しでも時間を、将来のメンテナンスコストを払うなら、それは悪いコードになるかもしれない。
他の人に作れないものが作れることが、作れるものが多いことが、技術力の高さだというならば
かつて薄型折り畳み携帯電話で高速データ通信を実現し、
そして今やろくにスマホなど作れない日本は技術力が高いのだろうか？
必要とされていないものなど、誰にも価値をもたらさないものなど、世界でただ自分一人が作れても、技術力が高いとはいえない。
たとえ、数十クロックを、数十byteのヒープアロケーションを、数行のコードを削る方法を知っていたとしても、
それが標準ライブラリの実装の世界でどれだけ当たり前だと感じていたとしても
どうかそれがすべてのアプリケーションで正義であるとは思わないでほしい、
どうかその「直感に反する」コードを書ける人であってほしい。
オブジェクト指向プログラミングはコードに対してオブジェクト指向ではないが、
コードに対してオブジェクト指向なプログラミングパラダイムがあってもいいではないか。
ここまで読んで、自分の技術力を否定されたかのように、すべてを失ったかのように思うかもしれない。
だが、安心してほしい。
技術力が、解決すべき課題によって、必要性に依存して測定されるパラメータであるならば
流動的で不可視の社会課題と需要に依存する以上、技術力も潜在的なパラメータということにならないか。
「しない」ことと「できない」ことの間には依然として差があるのではないか。
1フレーム以内で終了する最適なコードを書けることで可能になる映像表現がある。
SBCの少ないメモリに収まるコードを書けることで干渉・測定できる現実世界がある。
汎用的で利用しやすいコードを書けることで全世界に出せるライブラリがある。
必要であるときに、その知識は必ず技術力になる。
たとえ冥土に生前に書いたすべてのコードが見られる鏡があろうとも
必要がないからと、直感に反して書いたコードが悪いように評価されることはないに違いない。
どうか、必要なときまでしまっておいて欲しい。