【読書感想】 リーダブルコード （The Art of Readable Code） を読んで

こんにちは。すうちです。

先週後半から初冬を思わせる寒さでびっくりしましたが、皆さん如何お過ごしでしょうか。

私は季節の急激な変化に慌てて衣替えを始めました。とはいえ、もう１０月に入り今年も気付けば残り３ヶ月。別に早い訳でもなくそういう時期ですね。

今回は仕事が落ち着いて、久しぶりにインプットした本「リーダブルコード」を読んだ感想です。

はじめに

少し前にエンジニア界隈のSNSでも話題になってたので読んでみました。

最近出た本かと思ってましたが初版は２０１２年なんですね。恥ずかしながら今まで知りませんでした。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

概要

シンプルで読みやすいコードを書くにはどうするべきか？各テーマ毎にOK/NG のサンプルコード（言語はPython、C++、Java Script等）や具体的な考え方が紹介されてます。

最後の章は各テーマで実践した方法を使ってお題のプログラムを設計・実装していく過程を体感できます。

中身は技術書というより読み物に近いので、読書家の方なら１時間程度で読めると思います（全２００ページ程）。個人的にはなぜか途中に登場するスターウォーズのヨーダの格言も響きました。

タイトルの「リーダブルコード」の意味は、第三者にも読みやすいシンプルなコードを書く努力をすると理解しました。

そのために「コードの見栄えを良くする（インデント調整、※ヘルパ関数使用）」「関数、変数に適切な名前をつける」「タスク（関数）は一度に一つのことを」など紹介されています。

※ここで言うヘルパ関数は、コードの見た目を整えるため定義する関数と理解

リーダブルコードを読んだ感想

ここからはリーダブルコードの個人的な解釈と自身の経験の話です。

良いコードを書くには、以下３つのキーワードがある気がします。

1. 美しいコード

なぜコードに美しさが必要なのか？

それは、開発を円滑に進めるためと思います。

近年の開発は、全体を一人で作ることは稀で小規模でも数人。大規模開発では数百人が関わることもあります。

複雑なコードは後で修正が難しかったり、余計なテスト工数が増えたり、何よりバグを生む可能性もあるので開発やメンテナンスに支障が出ると考えられます（それ以前に明確なフローが定められた開発では、コミットやレビューが通らない可能性が高い）。

最初から人と共有する意識を持つ

ある開発で担当作業が遅延して先輩がサポートに入ってくれたことがありました。

最初の引き継ぎの際、私のコードは全体構造や個々の関数の処理がわかりにくく、サポートしてもらう前に説明や質疑に時間を取られて、その後お説教（ご指導）を頂いたことは若い頃の思い出です。

当時はキレイなコードを書く以前にソフトウェアのデザインパターン等も知らず、任された範囲が動けば良いという考えで進めていた事も反省点です。

ひとりで開発するプログラムであっても緊急時に助けてもらう場合にキレイなコードが書けていれば余計な時間を取られなくて済みます。

キレイなコードを書くのは自分のためでもある

前述の話につながりますが、では他人と共有しないプログラムにも美しいコードは必要か？答えはYesと思います。

それは未来の自分のためです。時間経つと昔書いたコードの中身を忘れてしまうことがあるからです（少なくても私はそうですが、皆さんは如何でしょうか）。

プログラムを拡張したりコードを流用して新しく作る場合など自分のプログラムの書き方が良くないと細かい所をあらためて調べたり、勘違いで誤った実装して時間を無駄にすることがありました。

またある時、仕事で作った自分専用のプログラムを急遽チームで共有する事になり、自分しかわからない雑な書き方だったので大幅に書き直したこともあります。

経験上、最初から共有する前提でコードを書くとプログラムは自然とキレイになる気がします。今後もその意識を持ち続けたいと思いました。

2. シンプルなコード

ソフトウェアのテスト手法に全パステストという考え方があります。プログラムの全てのパス（分岐条件）に問題ないか確認することです。

分岐が多い複雑なプログラムに全パステストを適用するとかなり時間を取られます（複雑なプログラムはパスを通す条件を作ること自体が難しいことも…）。

本の説明にもありましたがシンプルなコードはテスト時間を減らす事にも繋がります。

更に不具合をなくす一番の方法は「できるだけコードを書かない」の格言には共感しました。

また当然ながらプログラムを変更する際もコードはシンプルな方が失敗しずらいのは言うまでもありません。

コードの分岐が増えたり論理が複雑だと感じたら、一度手を止めて他に良い方法はないか考えることも必要と思います。

3. 再利用可能なコード

これもよくある話ですが開発中に「どこかで見たコード」と思うことがあります。

本にも同じ事が書かれてましたが、私は似たコードを何度も書く場合は、別の開発で使えるようにその処理をクラスやライブラリにして再利用します。

ソフトウェア階層や構造化を考える時に汎用コードは言語サポートのライブラリを活用したり、個人で切出した関数を使うことで本来の開発に集中できるメリットがあります（その結果、新規コードを減らす事につながる）。

こうして考えると、ソフトウェアもレゴブロックのような部品の集まりと捉えることもできます。

以前、AIアプリを開発するハッカソンに参加したことがありますが、そこに居たスーパーサイヤ人級（いつも例えがドラゴン◯ールになってしまう世代…笑）の凄腕エンジニアの方も同じことを言ってました。

ソフトウェアは共通する部分が多くあるので、そういうネタを切り出して部品として持っておくそうです。そして必要な時にストックしたネタ（汎用コード）を組合わせてプログラムを作ると最速で作りたい物ができるという話は説得力がありました。

コードを書く際に汎用コードで切出すべきかシステム依存のコードにすべきかを意識すると将来的なコード量を減らし時間を節約できるので、早く目的にたどり着けると私も思います。

最後に

原書タイトルは「The Art of Readable Code」。ソースコードをアートと表現するのが良いですね。

本の内容は正直言って、私は半分程度しか実践できてませんでした。仕事は期限もあり動くものを優先してコードの見栄えは後回しとなるのが主な理由です。

ただ、それが後に問題となった経験もしてます。そのため時間なくてできなかった事は繁忙期が落ち着いたタイミングでコードを見直すことが多いです。

文中で過去の失敗を書きましたが、良いコードを書くには良いコードをたくさん真似て自分の引き出しを増やすことも大事と思います。

本書は具体例と回答がセットなので分かり易いですが、若い頃の私のように引き出しがないと仕事で実践するのは難しいかもと思いました。

ソースコードをアートに例えるなら、私は満足いく作品ができた実感はまだないので、これからも試行錯誤しながら少しでも満足いくコードが書ける様に精進して行きたいです。

本書は他にも具体的な対策が紹介されているので、少しでも興味ある方は、ぜひ詳細を読んで頂ければと思います（名著です）。

最後まで読んで頂き、ありがとうございました。