「いいコード」を書くためにできること

GitHub の Explore におもしろそうなリポジトリが出ていた。コードが短く、ざっと読んで全体を把握できたので JavaScript で書かれていたものを勉強がてら TypeScript で書き直してみた。最初は単純に型をつけていただけだったが、ひとつの変数に数値と真偽値を代入している箇所の処理に悩んだ。

その変数は A という状態と B という状態を真偽値で表現すると同時に、B という状態のパターンの区別を数値で行っていた。つまり状態 A ならfalse、状態 B のパターン 1 なら1、パターン 2 なら2のように表現する。これに素直に型をつけるならboolean | numberで済むが、もっとうまいやりかたがあるのではないかと思った。

状態 A, B の区別を行う変数と、状態 B のパターンを表現する変数を別にしたり、OCaml のOptionや Elm のMaybeのように表現したりすることもできるだろうし、ほかにもいくつかやりかたが考えられた。しかし現状のやりかたも含めて、結局何がベストなのかという判断をすることができなかった。


コードの良し悪しは実装が終わって、あとから修正するときに評価されることがほとんどだ。案件の最初に「これはクールだ!」と思って書いた部分が、実装を進めている中で無駄に複雑なことをしているように感じられたり、共通部分としてまとめていた部分が融通がきかなくなってつらくなったりすることはよくある。

このあたりはどうしても経験がものを言う部分だろう。コードを書いて、読んで、修正して、という経験が多いほど、「こうやったらあとから処理を追うのが難しくなる」、「ここの仕様は変わることが想定されるので、柔軟に対応できるようにしておく」などのように、設計・実装するときに見えるものが多くなるはずだ。

案件が進む中でデザインが変わったり、最初は全体像がうまくつかめていなかったりということがある中で、決められた時間内に納品するためには常に 100 点満点のコードを書くことはなかなか難しいかもしれない。

それでも、案件が終わったあとにはかならず自分が書いたコードを振り返ったり、今回のようにいろんな OSS のコードを読んで触ってみたりすることできっと上達できるだろうし、もっとうまくコードを書けるようになりたいと強く感じた。