はじめに

こんにちは、Kotaです。
4月も終わりが近いですね。

社内では新卒社員5名（4名：総合職、1名：エンジニア職）が新たな仲間として加わり、メンバー一同活気に満ちています。

そんなSAKURUGでは、入社1～2年目の新人研修の一環として『課題図書』があります。
一人一人の成果向上に向け、研修担当者からの推薦書を読み、業務に反映させるというものです。

入社2年目エンジニア職の僕は、『リーダブルコード』を拝見しました。
そこで今回は、本書からの学びや感想を共有したいと思います（要約ではありません）。

理解しやすいコードとは

改めて「理解しやすいコード」とは何なのでしょうか。
本書では以下のように提唱されています。

コードは他の人が最短時間で理解できるものように書かなければいけない
（本書1.2 「読みやすさの定理」より抜粋）

そのままです。見た目が美しいとか、とても複雑な処理が行われている頭の良い人が書いた凄いコード、ではありません。そのコードをなぞれば何が行われているのか理解できる状態でなくてはなりません。

まさに今の僕の課題にも繋がる部分があります。
これまではとにかく「要件を満たすもの」を最優先にコードを書いてきました。その過程で可読性も意識はしているものの、それすら主観的な評価になってしまっていたので自己満足でしかありませんでした。

あくまで1番の優先度は変わらないのですが、理解しやすいコードを書くことも同等の価値があり、自分のコードに対する意識が一つアップデートされたように思います。

「ネストが深くて読みにくいけど、時間があるときにリファクタリングすればいいや」ではなく、「このロジックはもっとシンプルに収まるんじゃないか？」という前提で書く。そしてリファクタリングの時間も予め確保しておくべきですね。

1～2章の、コードの見た目に関する内容は比較的すぐにでも実践できる気がするので、まずは「1～2章の内容を当たり前にする」ことを目標に始めてみます。

個人的な学び

理解しやすいコードを書くうえで、「短いコード＝理解しやすいコード、ではない」という考えが個人的には一番刺さりました。違うんですね、、。

三項演算子なんかが良い例なのですが、一行で収まるからと言って無闇に三項演算子を用いるのはBADパターンのようです。

return (events.length === 0 ? true : false);

↑これくらいならば三項演算子の恩恵が感じられますが、

const randomNum = minAry.length === 0 ? Math.floor(Math.random() * maxAry.length) : Math.floor(Math.random() * minAry.length);

↑ここまでくると「理解しにくいコード」です。
まず単純に長い（一般的に、一行あたり80文字程度が許容範囲らしい）のと、一行で複数のタスクが行われているのです。

上記の例の場合は、複数行になってでもif elseで明示的に行を分けるべきです。基本的には「1行1タスク」で上から下に読み進めるだけ、という状態が理想であると認識しておきましょう。

実践に向けて

結局1周読んだからと言ってすぐにコードの質は変わるはずもないので、しばらくは傍に置いておき、適宜読み返すことになるかと思います。実際、既にそうなってます。

これまでも変数などの命名時には頭を悩ませてきたのですが、本書を読んだことでより一層悩むこととなるでしょう。

因みに、現時点で投稿されている本ブログの過去のコードはまさに改善の余地しか無いと自負しています。。。
今後コードの品質が改善されていく(筈です)ので、その過程も含め、今後ともSAKURUG TECHBLOGを宜しくお願いします。

ではまた次回！