第三回輪読会【リーダブルコード12章13章】まとめ！今回はコードを管理していくためにええ感じに考えていこうや。そんなお話。エンジニアだと保守とか文章化といったメンテナンスを忘れがちですよね。そこを忘れたらいかんよというお叱りとコードを継続的にメンテしていくために必要な考え方やロジックが書いてあります。ぜひ！原典をご一読ください。

どもども！龍ちゃんです。輪読会もふんわりと続いています。今のところ２週間に一度、担当が廻ってきます。ゆるゆると予定を進めていても、予定として入ることで身が入ります。こう考えると人間って案外単純なんだなと思っちゃいます。計画の重要性を再認識ってやつですね。

ほい！というわけで今回も「リーダブルコード」についてまとめを書いていきたいと思います。今回の僕の担当分は12~13章になります。担当分の章タイトルは以下になります。

コードに思いを込める
短いコードを書く

タイトルだけ見れば、抽象的と具体的の間で反復横跳びしそうになりますね。

でも安心してください。一貫して見やすく、わかりやすいコードを書くためのエッセンスがまとまっているだけです。それでは初めて行きましょう。

その前に前回の記事たちです。

1 12章「コードに思いを込める」
- 1.1 まとめ
2 13章「短いコードを書く」
3 ブログのまとめ

12章「コードに思いを込める」

いきなり名言が置いてある章はおしゃれだなという感想です。というかアインシュタインってこんな名言残していたんですね。12章では「コードに思いを込める」といったタイトルですが、内容としては「コードの中身を単純化するための一つの手法」について紹介しています。12章で用いている手法としては以下の引用になります。

コードの中身を単純化するための手法

コードの動作を簡単な言葉で同僚にもわかるように説明する。

その説明の中で使っているキーワードやフレーズに注目する。

その説明に合わせてコードを書く。

それでは、手法の流れにのっとりTipsをまとめていきたいと思います。特に重要な概念としては「コードを簡単な言葉で説明する」ということです。

流れを図化すると上記の内容になります。プログラミング最中の脳内でこの動作を自然にやっていますよね。それを文章として整理していこうというのがこの章で僕が受け取ったメッセージになります。この図の中の「解決したい問題・要件・要望」がふわふわしていることが実装面で跳ね返ってくる経験をしたことはありませんか？ここを明確に認識するフェーズを挟むことで、実装した際の問題を回避することができます。

概念や手法を言葉で説明するのが限界があるので、例を立てて説明していきたいと思います。

この章の方法を用いて分析をすると上記の様になります。言語化した内容ではまだ不十分である可能性があるので、コードレベルまで言語化を繰り返していきます。例えば以下のようになります。

この言語化の手法をコードの作業レベルまで繰り返して落とし込むことでコードがより洗練されていくと記載されていました。実際、多くのプログラマーは脳内でこの処理を行っていると考えています。僕がフロントエンドエンジニアなこともあって、フロントエンドよりな内容になっています。フロントエンドだと、ワイヤーフレームなどでこの辺は整理します。

何を実現したいのかを整理することで、デバックやリファクタリングに効果を発揮しそうです。また、きちんと整理することでライブラリを使用すれば解決できる問題を浮き彫りにすることが可能になります。ライブラリを使うことのメリットは次章でも触れますが、ライブラリに移管できる部分は積極的に移管することがこの章でも勧められていました。

まとめ

実現したい内容を「簡単な言葉で言語化」することで、コードに対する考え方を整理することができる。言語化を繰り返すことで、コードの問題点の発見やブラッシュアップができるかも？？

「ラバーダッキング」：自分が学習したことを他人へ説明することで、学習の理解度をより高める方法。あるゼミでは、デバックに悩んだ際に教室の隅に置いてあるテディベアに向かって説明をするらしい。

13章「短いコードを書く」

センセーショナルな内容が置いてありますね。この章でのエッセンスとしては、自前でコードを製造することを控えようという内容です。自前でコードを実装するということは、テストして保守してというメンテナンスが発生します。ライブラリを使用することで、自前の実装を減らしメンテナンス時間を割くことが商業プログラマーには必須の能力の様です。

プログラマーの特徴として、「プロジェクトに欠かせない機能を過剰に見積もってしまう」と「メンテナンス（テスト・文章）などにかかる負担時間を忘れたりする」といった特徴があげられていました。一般プログラマーとしてこの特徴に当てはまるなと中心を撃ち抜かれてしまいました。

この章でのエッセンスは以下になります。

短いコードを書くための工夫

質問と要求の分割

コードを小さく保つ

身近なライブラリに親しむ

コードを使わなくても解決できることもある

質問と要求の分析

こちらでは、たびたびネットに挙がってくる「顧客が本当に欲しかったもの」がクリティカルな表現だと思います。最初に聞いた要求がすべてだと思うと、実際の要求と乖離してとんでもないシステムを作らないといけなくなったりする可能性があります。エンジニアの皆さんは、要求を正しく認識していきましょう。ブランコを作ればよいのにバンジージャンプを作ったらお客さんびっくりしちゃいますからねｗ。

愚直にすべてを実装すると膨大なコードになるが、要求を詳しく分析することでコード量が激減したりします。要求を正しく整理することで、より早く短いコードで実現した例をかみ砕いて説明していきます。

例：店舗検索システム

商用の「店舗検索システム」を作っていると仮定する。一般的な要求としては「任意のユーザーの緯度経度に対して、最も近い店舗を検索する」というものになる。これを正確に実装しようとすれば、以下の内容を実装する必要がある。

日付変更線をまたいでいるときの処理
北極や南極に近い時の処理
「1マイルあたりの経度」に対応した地球の曲率の調整

この実装をまじめに行うと膨大なコード量になると考えられる。だが、要求を分析していく過程で「限られた地域での30店舗」の中から近い店舗を検索していきたいという要求があらわになった場合、先ほどの三項目を考慮する必要がなくなりコード量が削減される。現代であれば、Google Maps APIなどを使用することでコード量を大幅削減することができそうである。

最初の要求から分析を重ねて、隠れた前提条件を見つけることでコードが削減することができる可能性がある例である。

例：キャッシュを削除する

キャッシュを使用しているシステムで、「キャッシュを削除する」要求が生まれたと仮定する。別プロジェクトで100行のキャッシュ削除プログラムをそのまま適応するとコーディング量が0で作成することができた。この前提だと、要求の分析が必要ないように感じられる。だが、要求を分析することで「必ず同じ順番でアクセスが行われる」という前提を発見することができた。これを要求と組み合わせて実装することで、新しいコードを作成したところ1/4のコード量で90%のメモリ削減を実現した。

コードを小さく保つ

コードを小さく保つことは、長期的な面でとても効果的です。8年前書いたコードを機会があって除いたことがあります。一つの関数で10個以上の処理を書いたコードがありましたが、地獄ですよね。作っているときは理解しているので、ルンルンで作っていました。今読むと地獄がそこにありました。商用プログラマーの皆さんは、書いたコードがブラックボックスになることはほとんどありません。誰かがいつかメンテナンスを行います。その時のためにもコードを「コードを小さく保つ」ことを意識しましょう。

以下がコードを小さく保つためのTipsになります。

コードを小さく保つためのTips

汎用的な「ユーティリティ」コードを作って、重複コードを削除する

未使用のコードや無用の機能を削除する

プロジェクトをサブプロジェクトに分割する

コードの「重量」を意識する。軽量で機敏にしておく

「重複削除」や「未使用コード」の削除は気づいたときにはすぐできるので積極的に行っていきましょう。

「コートの重量」や「サブプロジェクト」についてはコーディングを行う段階で意識を持っていないと難しいです。前章で学んだ「言語化」を用いて適切な粒度でコードを分割していきましょう。

ちなみにですが、リーダブルコードのp171で「未使用のコードを削除する」というコラムは一読の価値があるので読んでみてください。強めな言葉で使っていなコード削除について語ってあります。確かに「未使用のコードは悪だなぁ～」という感想と決意がもらえます。

身近なライブラリに親しむ

3時間かけて作ったコードが、ライブラリを組み合わせたら10分で実装できたみたいな経験ありませんか？この節では、そういったことを極力なくしていくためにということが書いてあります。

コードを書いた分だけ文章化やメンテナンスの手間が増えることは何度も書きましたが、標準のライブラリを使用することでメンテナンスの手間を大幅に削減することができます。標準になるまでの長い歴史の中で、研磨されて洗練されているのが標準のライブラリです。たまにメジャーアップデートで標準ライブラリが変更されることがありますが、それだけ進化の余地があるということで喜びましょう。

ここで重要なのは、標準のライブラリといった成熟したライブラリを使用することが時間削減の助けになるという点です。未熟なライブラリを使用することは、むしろリスクになるのでお気を付けください。僕はプロジェクトで未熟な（実験的な側面のある）ライブラリを使用しようとして上司にリジェクトされた過去を持っています。

本節では、標準のライブラリについて斜め読みすることを推奨していました。すべてを覚えることは不可能ですが、頭の片隅に置いておくことでいつか助けになるかもしれません。あなたも使用頻度が高い言語の標準ライブラリのドキュメントを読んでみましょう。

コードを書かなくても解決できることがある

一度しか行わない作業で、10分間Excelで行えばよい作業を3時間かけてシステム化する話についてどう思いますか？とても費用対効果が薄いですよね。そんなお話です。

現代では、便利なツールがたくさんあるのでコーディングはあくまで問題解決の手段であることを再認識させてくれる節です。

まとめ

この章では、極力コードを書かないことについて書かれていました。コードを書くことが仕事のプログラマにとって、極力コードを減らすことを工夫するというのが面白いところですね。でも、仕事ですので仕事の予算と総量を見て最適な判断をすることが求められるものです。時間は有限なので、余計なコードは書かないということを意識してみてはどうでしょうか？