良いコードを書くために良いコードを読む

仕事の中で「良いコードを書くためには何をするべきか」について考える機会があった。 今日の自分の答えは「まず良いコードをたくさん読む」というものだったが、せっかくなので少々掘り下げて考察してみたい。

「書く」に対して「読む」はものすごく重要だ。1行を書くために1000行を読んでもいい。

プログラミングの学習を外国語の習得に喩えるならば、「良いコードを読む」ことは「語彙を増やす」ことに相当するだろう。 中学1年生の語彙のみをもって、ネイティブスピーカーのように話すことは不可能なように、基礎的な書き方の知識のみをもって プロフェッショナルのようにコードを書くことは難しいだろう。

(ただし、プログラミングの学習の場合、「真の未知語」が登場しない点で自然言語の学習と異なる。 これはつまり、膨大な試行錯誤を重ねることで熟達することが可能であることを意味する。 この性質があるがために「プログラムを読む」ことの必要性が低く見積もられてしまっている部分もあるかもしれない)

……シャワーの中の考察は不思議なもので、身体を拭いているうちにだいたい忘れてしまう。 いろいろ考えていたような気がするが、もはや一片も思い出せない。

そこで、以下に「良いコードを読むと言っても、良いコードとやらはいったいどこにあるか」について書いてみる。


プログラミングの新しいパラダイムを習得するとき、今の自分がたどるであろう過程について考えてみる。 例えば、いま新しくReactについての知識が何もない状態で、SPAを書き始めるとしたらどうするだろうか。

まずは公式ドキュメントを紐解くだろう。Getting Startedのような項目があればそれに従って開発環境を整えつつ、急がば回れ、まだたくさんのコードは書かない。 各種コンセプトについてよく読む。ドキュメントの序説に登場するソースコードをじっくり読む。 多くの場合、このコードがそのライブラリやパラダイムが理想とするコードであり、基礎とすべきコードだからだ。

書くべきコードについての指針が得られたと感じたら、適当にコードを書き始める。 ここは適当で良い。公式ドキュメントを読んだとしても、最初から最高のコードを書けるほど自分の能力は高くない。 サンプルを適当に変形させつつ、関数を切ってみたり、コンパイラやlinterに怒られたりする。 Rules of Hooks、なるほど、そういうのがあるのか。不思議なルールだ。

動かしかたがある程度分かってきたところで、コードの質について信頼できそうなアプリケーションのコードを眺めてみる。 この頃になると、疑問はある程度明確になっており、読むべき部分のアタリはついているはずだ。 なるほど、こういう単位で Context を切ると後から取り回しやすいのだな、という具合。 (ここで難しいのが「信頼できそうなアプリケーション」を探すことだが、自分の場合はGitHubで公開されている 著名なアプリケーション、それもできれば自分がユーザーとして使ったものをいくつか探してみることにしている。 例えば、Goを使ったAPIサーバーを書きたい時は、ユーザーとしてよく使っているPrometheusのコードを見てみる、という雰囲気)

そして、最後にライブラリそのもののコードも読んでみる。例えば、「カスタムフックは use* という名前でなければならないらしいが、 JavaScriptでそのような制約をどのように実装しているのだろう」というような疑問をとっかかりに、Reactの全体の構造を簡単に把握していく。 広く使われているライブラリのコードはこなれていることが多く、その機能の複雑さに対して驚くほどシンプルに記述されていることが多い(9ただしRailsは例外))。

……というような調子で、次から次へと様々なコードを読んでいるように思う。 小さなライブラリであれば、最初からその全部を読んでしまうこともあるし、必ずしもライブラリの中までしっかり読んでいるわけではない。

例によって抽象的な感じになってしまったが、飽きたので今日はここで終わり。次はもっといいことを書きたい。