OSS とかのコードを巡っていると、時々「すごいコード」に出会うことがある。 もちろん「すごい」と言っても色々な凄さがあって、「読みやすくメンテしやすいコード」とか「技術的に凄いことをしている」とか「最新のライブラリを上手く使っているコード」はもちろんそうなのだが、それ以上に「圧倒される」コードがある。
全部頭に入ってる人が一気に書いたコードって、なんか見て分かるよね。また出会った。
— Yosuke Torii / ジンジャー (@jinjor) 2020年9月18日
凡人の発想と違うことがあり、一見して読みにくく取っつきにくいこともあるが、そういう感想はすぐに吹き飛んでしまう。
その特徴を思いつくままに列挙してみる。
- 癖があるが終始一貫した書き方
- 世に出回っているベストプラクティスに則っていない
- フォーマッターを使っていない
- 細かいユーティリティ関数がない
- 初手で完璧に近い
- 静的型でないコードも多い
- 可読性のためにパフォーマンスを犠牲にしない
- とにかく無駄がない
- テストがないこともある
別に型やテストがないのは見習うべき点ではない。一方で、これは絶対に真似できないなーと思う。
もし「独りよがりな書き方してんな！俺がマトモにしてやる！」とリファクタリングを始めたとしたら、しばらく経ってたちまち鬱になるのが目に見える。 3 行のコードが 20 行にフォーマットされ、共通化はしたものの良く分からない名前の変数や関数が増え、たまに共通化したコードを使い忘れている箇所があり、やたら型が増え、宣言的なのに簡潔でなく、無駄にメモリを食い、後になって「ここは共通化すべきじゃなかった」と言って戻す。
じゃあなんで彼らはそういうコードが書けるのかという仮説、あくまで仮説を立ててみる。
- 圧倒的な経験量。こういう時はこう書くというパターンが予め頭に入っているために迷いがない。迷いがないからコードの書き方に関して雑念がなく、本質的な部分に集中できる。昔から書いていたのでスタイルは古いが、メモリを食いにくい書き方が常に意識されている。細かいアルゴリズムは頭に入っているのでユーティリティ関数を使わなくてもすぐに書けるし、逆に書かれたパターンからアルゴリズムを瞬時に読み取ることができる。
- 圧倒的な知識量。技術的に十分な知識を持っていれば、予め何が出来て何が出来ないかが把握できるので適切な設計ができ、行き当たりばったりにならない。セキュリティ的に考慮すべき点は最初から網羅できる。仕様書を読めば実際に試さなくても何が起こるか把握できる。
- 上記２つを効率良く高速で摂取する頭の良さ。
優れたプログラマは頭の中で全てを組み立て、手を動かし始めたら一気に頭の中にあるものを吐き出すだけ、と良く言われる。 翻って凡人プログラマである自分は逆に何をしているのかというと、とにかく常に迷い、試行錯誤している。
まず知識量の不足から仕様書を確信を持って読むのがとにかく難しい。簡潔に書かれているそれらは、おそらく背景知識があれば自明なのだろうが、一部が抜け落ちていると理解が困難になる。そして「分からん！とにかくサンプルをくれ！」となる。サンプルを通してやっと「あれはこういうことが言いたかったんだろうな」と理解した気になる。試行錯誤しなければ分からないとなると、大きな時間のロスになる。一つ確かめるのに20分かけてデプロイしたら、３回で１時間。なかなか進まない。また、サンプルにないパターンを自分で組み立てるのは不可能なので、「とにかく自分のやりたいことと似たことをやっているコードがないかググって探す」ことに時間を費やすことになる。まるで何か未解明の自然現象に触れるかのように「あれをしたらこんなことが起きた」を繰り返すのだが、実際にはブラックボックスでもなんでもなく仕様はちゃんと書かれている。
試しながら書いているととにかく書いている時間が長いので、書き始めた時と書き終わる頃で気分が変わって一貫性がなくなっていく。ある時は関数を上に書き、ある時は下に書く。その時々で「これで行こう」と判断した形跡が、ミクロにもマクロにもある。タイピングも遅いので同じコードを何度も書いているとだるくなってきてユーティリティ関数を作ったりする。が、関数を一つ作るということは名前を一つ考えるということでもあり、名前こそその時々の気分が反映される。行き当たりばったりで生み出した謎概念を、拙い英語（しかし簡潔に表現しようとして短くして情報が不足している）で表現しているのだからタチが悪い。
