コードリーディング===本を読むこと
はじめに
これは私がエンジニアとして経験してきたわずかな知識を言語化した。
いろいろな考え方がある中の１つであると思っていただきたい。
絶対にこれが正しいわけではないし、他にも素晴らしい考え方や哲学がある。
そのような視点で私の哲学を聞いていただけると嬉しい。
そもそもコーディングとは？
コードリーディング（コードを読んで理解すること）を考える前に、コーディングが何かをちゃんと理解していきたい。
一旦ここではコーディングを、コンピュータに命令をするために用いられる「機械語」をどうにか人間にも理解できるように生まれた「高級言語」を書くこととする。
コーディングは絵を描くこと
かの著書、「ハッカーと画家」でも言われているとおり、ハッカーと画家は同じことをしている。
理由は簡単で、お互いに「無→有」を作り上げている。
さらに「美」を追求し続けている。
真っ白のキャンパスになにか絵を描くことと、真っ白のエディタにコーディングすることは同じことだ。
もし、りんごを描くというお題に対して画家が全員同じ絵を描くだろうか？たぶんみんな違ったりんごを描くだろう。
コーディングも同じで、なにかシステムを作るときにエンジニア全員が全く同じコーディングをすることはほぼありえない。
エンジニア全員が想像力、経験則から一番美しいコーディングを心懸けることを無意識にしている。（そうでない人もたまにいるが、それもアートだ。）
コーディングは本を書くこととも言える
絵を描くこととも言えるが、私は「本を書く」ことにもすごく近いと考えている。
本やブログとかで、なにか文書を作るときは、必ず相手に「伝わりやすさを意識して書く」ことが一般的だと思う。
中には、あえて例を加えたりしてより理解を深めるような書き方もある。
それは、読む相手が同じ「人間」であることを理解し、その人達に順序立てて内容を整理してわかりやすく伝える行為である。
もちろんこれも千差万別で、多くの人に同じタイトルを渡したとしても絶対に一言一句、一致していることはありえない。
そう考えると、とてつもなくコーディングに似ていると思えないか？
コーディングするときも、見やすくわかりやすくというのも大事にするし、そもそも文脈を意識した設計、コーディングをすることによって、美しいコードが出来上がる。
「目次、タイトル、文書」は、「フォルダ構造、ファイル・クラス名、コード」のように置き換えることもできる。
そして読んでいる人に「ストーリー」を感じさせることさえできるはずだ。
この「ストーリーを感じさせる」というのがとてつもなく重要だと考えている。
例えば
const title = 'コーディングとは？';
let subTitle = 'ハッカーと画家';
このコードだけでも、作者が何を意図しているのかを考えることができる。
私はzenn.jsを見て、「これはzennのブログを書くための処理なのかな？」という考えから、「titleは、このあとの処理では変更したくない不変の変数」だな。また、「subTitleはこのあと何かしらの処理で変更されうる可能性がある」と解釈をしてから、具体的なコーディング（文書）を読んでいくことになる。
こう考えると、高級言語はこういったことを伝えるためにできているのではないか？と考えることのほうが正しい気がしている。
逆に、ストーリーをおろそかにしている人は、結局は独りよがりな「日記」を書いているにすぎない。
そのような文書に興味もわかないし、何を伝えたいのかのまとまりもない場合が多いし、とにかく修正が困難。
ストーリーが正しく伝われば伝わるほど、どこにどういった修正をすればよいのか、ストーリーそのものが崩れないか、がすぐに理解ができるのだ。
コメントアウトは邪道か？
コメントアウトには賛否が分かれると思う。
ただ、私はなるべくコメントアウトは書くべきではないと思っている。
それは、自ら自分の書いた本（コーディング）は読みにくいということを表している。
コメントアウトがなくても理解できる本を書いたほうが、技術力が高いと私は信じている。
コードリーディングとは？
ここまでの説明を通して、私が考えるコードリーディングとは「本を読むこと」である。
本を読むように、この作者は何を考えながらこのディレクトリに、このファイル名で、こういったコーディングをしているのかなどの背景をしっかり掴みながら読むことだ。
そうすることで、作者の立場に立った感覚でコードを読むことができて、なんでこのような設計になっていて、このような処理を書くのかが、頭ではなく体で理解できる。
作者のストーリーをしっかりと感じ取れれば、そこに修正を加えるのも容易にできるようになる。
しっかりと作者の意図を読み取ろう。
読み取るには、それなりにコードをたくさん読まないと身につかないことも多い。
しかし、段々と作者の気持ちや考え方を捉えられるようになってくると、ものすごく楽しい。
初心者にありがちな罠
初心者にありがちで、コードリーディングをする際に「ロジックを読み解く」姿勢になってしまっていることがある。
それでは一向に作者の意図に気づくことはできない。
ロジックはあくまでその作者の言い回しで、伝えたいことは別にある可能性が大きい。
なので、まずはコードリーディングは本を読むことだと理解してもらいたい。
そして、ディレクトリ構造やファイル名から何をしたいのかを掴んで、作者の気持ちになってほしい。
結局、DDDやデザインパターンなども、難しく捉えず、本を書くときのフレームワークだと思ってもらえれば良い。
どれだけわかりやすく伝えるかを意識した結果のたまものなのだ。
まとめ
はじめにでも書きましたが、あくまで私個人の哲学だ。
ただ、これに共感をしてくれるエンジニアが周りに多数いることも事実。
エンジニアは理系という意識が強いと私もはじめは考えていた。
でも、こういったコードリーディングから、エンジニアにも国語の力が重要な気がしている。
コードリーディング===本を読む
この原理原則を意識すると、もしかしたらまた違った視点でコードリーディングの面白さを見つけられるかもしれない。
Discussion