【読書メモ#1】エンジニアのバイブル『リーダブルコード』_後編
ご挨拶
こんにちは！スーパーソフトウェアの鈴木です。
こちらの記事はエンジニアのバイブルとも言われる書籍『リーダブルコード』を読んだ感想&書評レポの後編です。
『リーダブルコード』の第7章以降の内容について触れております。
もし前編をまだ読んでおらず、前章も気になる！という方はこちらの記事をご参考ください！
（前編レポートのURL）
本書について
※こちら前編と内容は同じです。
総ページ数は200pほど。本書の目的は「読者のコードを読みやすくすること」と書かれているように、命名の基本的な考え方から処理のまとめ方などについて書かれています。章立ては難易度順となっており、後半へ行くほど応用的なものとなり、熟練者の方々がオススメされるのも納得の内容でした。
以下、本書の章立てになります。
（太字箇所が本記事で触れている部分です。）
はじめに
第1章 理解しやすいコード
第1部 表面上の改善
第2章 名前に情報を詰め込む
第3章 誤解されない名前
第4章 美しさ
第5章 コメントすべきことを知
第6章 コメントは正確で簡潔に
第2部 ループとロジックの単純化
第7章 制御フローを読みやすくする
第8章 巨大な式を分割する
第9章 変数と読みやすさ
第3部 コードの再構成
第10章 無関係な下位問題を抽出する
第11章 一度に１つのことを
第12章 コードに思いを込める
第13章 短いコードを書く
第4部
第14章 テストと読みやすさ
第15章 「分/時間カウンタ」を設計・実装する
特に印象に残ったところ
〇第7章/第8章 制御フローと巨大な式
第2部からはコードの内部に関する改善点について書かれていきます。第1部までは表面的かつすぐに実践に移せるもので、コードレビュー時に意識するものという印象でしたが、ここからは実際にコードを書く時に必要になってくる視点だと思いました。また、こちらの章からは実際にコードを書いた経験があると、より理解がしやすい内容になっていると思います。
➤ 三項演算子
三項演算子を覚えたての頃は、この記法の方が行数が減らせるし簡潔なコードになる！と使いまくっていました。しかし、現場で三項演算子をif/else文にした方がいいと指摘を受けることもあり、自分で振り返るとそれは三項演算子にするのに悩みまくっていたコードの箇所でした。コードが簡潔になることは「見やすい」という点で大切ですが、大前提として「理解しやすい」コードであることを求めなければいけません。書く人ですら書き方に悩んだコードが、読み手に伝わりやすいわけが無いよな、と反省したのをこの章を読んで思い出しました。
➤ ネストを浅くする
この考えも基本的なもので、よく言われるものかと思います。ただ、この章で私が自分に向けて思ったのは、「最初からネストの浅い文を無理に考えなくてもいい」です。ネストの浅い処理を実装するのに苦がない場合はかまわないですが、ネストを深くした方が書き始めやすい、という場合は先にそう書いてもいいと思います。最終的なコードを仕上げる際に、ネストを浅くしたものを作成できるよう自己修正できることが大切です。
こちらは自己レビューの力も必要だなと追加で意識したポイントでした。
もっと実践的なネストを浅くする思考についてはぜひ本書をお読みください！
➤ 説明変数を使う
巨大な式を分割する時に有効な手段として「説明変数」が強く押されていました。聞いたことが無い言葉だったのですが、読んでみると現場で貰ったアドバイスが「説明変数」のことだったのかと、今更ながら深く理解できました。
〇第11章/第13章 コードの再構成
第3部では実際に作られたコードを再構成する視点に移ります。この視点を身につけると、一次コードを書く時はもちろん、自己レビューやコードレビューにおいてコードをより簡潔かつ読みやすくするアイデアを生むことに役立ちます。また、より技術的に深い話をするようになっているので、これもまた何度か現場を経験してからまた読み直すとより理解度が上がると思います！
➤ 一度に1つのタスクを行う。
これはコードを再構成する中でも最も簡単な技法のひとつです。また、関数を分割させるときに大事なのは、「どう分割するか」よりも「分割する」という一点です。関数の中にあるタスクを列挙すれば、大きな関数の中には分割できる点が見つかります。「一度に1つのタスクを行う」を徹底することは、初歩的かつとても効果的な技法なのでぜひ覚えておきたいと思います。
➤ 身近なライブラリに親しむ。
普段自分がコードを書くとき、その言語にどんなライブラリがあるか不勉強であったことを痛感するときはよくありました。機能を実装させることは楽しいですが、その前に基礎的なところに目をやれていなかったというのは、コードを書くことに慣れてきた時期の人には特に要注意の点ではないでしょうか。
〇第14章 テストと読みやすさ
直前まで入っていた開発で、初めてテストコードを書くことを経験しました。それまではテストコードを書いた経験はなかったため、本当の意味で初心者的なコードの作成をしてしまっていたかと思います。14章を読んだとき、コードレビューで指摘されたいくつものアドバイスが記載されていて、できることならもっと早くに出会っておきたかったと強く思いました…！
➤ テストを読みやすくて保守しやすい文にする。
テストコードを読めば「本物のコードの動作と使い方を理解できる」というのは現場でテストコードを書いていた時も感じていたことでした。だからこそテストコードが読みやすい＝本物のコードの動作が理解しやすいというのも理解できます。テストコードはしっかり細かく詳細なものにしなければ！というこだわりもさじ加減が大切で、反対にこのテストコードは無駄に大きくしてしまっていないか、という意識はテストコードを書く上でまだ自分が持っていなかったものでした。
➤ テストの機能に名前を付ける
「テスト名は長くなってもいい」と「Test_<関数名>_<状況>」と言った形式が基礎的な思考であることを再認識しました。テスト名には説明的な名前をつけて、何をテストしているか明らかにすることが重要です。現場で実際のテストコードを見たのでよくわかりますが、本当に説明的な名前を付けます。
こちらは一度書いてみないとうまくイメージできないなと個人的に思いました。
最後に
前編後編に渡り、何度も『リーダブルコード』はコードを書くバイブルと言ってきましたが、個人的には自分の中に具体的な経験があるとなお良い参考書になると書籍だと思いました。
読みながら「このルールはどこも共通していたな」とか「あの時書いたのコードはもっと良くすることができたな」等、自分の中に参考例があったことは本書をより深く読み込めるポイントになっていたと思います。
本書を読んで、新しい発見もありましたが、一番の収穫はこれからのコードの書き方にひとつの軸を作ることができたことです。
この本を読んだ後に現場のコーディングのルールを見直すと、意識して覚えなければと思っていたポイントが、どうしてそのルールがあるかを理解でき「この現場はこのルールが明示されている」という解釈をできるようになりました。
本書を読むことでコードを書く時の視野や注意点に自ら気づけるようになり、現場のルールを「覚えるもの」から「確認するもの」と認識できるようになったことが一番の成長だと思います。
もっと早く読んでいればと思う本No.1でしたが、弊社の「スーパーチャレンジ」のキッカケが無ければもっと遅かったと思います。スーパーソフトウェアには自己成長に繋がる書籍などの購入を支援してくれる環境が整っています！技術力を磨きたいエンジニアにとってはとても有難い制度でした。
次の書籍はまだ検討中ですが、自己のスキル向上に向け技術書の購読&アウトプットは習慣にしていきたいと思います！
後編も最後までお読みくださり、ありがとうございました！
鈴木
▼採用情報
▼新卒情報はWantedlyで