書評:リーダブルコード

発刊当時

2012年初版の本です。
当時、私はIT業界に勤めて2年目を迎え、大手保険会社のシステム統合案件に参画していました。

ただでさえ大規模開発なうえ、何度も(確か4度目でした)リプランを繰り返していた曰く付きの案件でした。

そんな中へ、2年目のひよっこ(わたし)がフレームワークを作り変えるために投入されることになったのですが、何せ「正しさ」がわからないので困り果てました。

そもそものスキル不足に加えて、"みんなが使う"ことを考慮したコーディングがよく分かりません。

現実味のないWBSが用意されていましたが、毎日キレイに1日ずつ遅延が拡大し、完全に「絵に描いた餅」となってしまいました。

リーダブルコードと出会う

で、「なんだよ、、掃き溜めみたいなPJやんけ。。」と思った矢先にリーダブルコードと出会いました。

この本は私のコーディングに対する姿勢、またコードからどのように第三者に評価され得るのかを考えさせてくれました。

と小難しいことを言っていますが、中身自体は非常に読み易いです。

ネーミングの大事さや、処理を分割してコーディングすること、グローバル変数を避け、リターンは早くなど、とにかくシンプルさを終始強調しています。

思想としてとても大事で、必ず頭に入っていないといけないコーディングの基礎が集約されています。
何度も読み返したい本の一つです。

各章の紹介

2章 名前に情報を詰め込む

どんなものを使うにしても、プロジェクトで一貫性を持たせることが大切だ。

まさにその通り。
簡単なようでいつの間にか崩れているものです。
特に私が参画していた案件にはオフショアに任せていた開発機能もあり、それはそれは残念な仕上がりでした。

"一貫性"は思想のような抽象的ものから、変数やメソッド名等の細部に渡るまで貫き通されるべきものです。

明確な単語を選び、不必要に長くなく、そして"意味を失わない"命名であること。

私を指導してくれた人はこの"状態"を「過不足がない」と表現し、教えてくれました。

システムエンジニアは、ロジカルシンキングには強いけれど様々な表現(コミュニケーション、コーディング然り)に過不足が散見されます。

エンジニアスキルの1つとして「命名力」を加えて欲しいくらいです。

4章 美しさ

優れたソースコードは「目に優しい」ものでなければいけない。

何万Step(この指標は心底嫌いですが)も読み込んだエンジニアでなくとも、一瞥すれば目に飛び込んで来やすいかどうかはわかるはずです。
実際、私の勤め先にやって来る新入社員に聞いたって、ソースを見たときの印象が、私と食い違うことはないです。

一貫性のあるスタイルは「正しい」スタイルよりも大切だ。  

これは前述の2章とも関係します。
それなりのPJ規模になると、細かなコーディングスタイルを知った上で開発しないと、
「Aさんが作った機能はキャメルケースなのに、Bさんはスネークケースで変数を命名してるね。」
なんてダサい指摘を受けることになります。

ですので、PJにはまず間違いなく「コーディング規約」があります。

私はリーダブルコードを全員に読んでもらったら十分だと思うけれど、PJ固有のシステム構成に紐付く内容などは特記するしかないでしょう。

5章 コメントすべきことを知る

コメントするべきでは「ない」ことを知る。
コメントの目的とは、コードの意図を読み手に理解してもらうことである。

コメントは結構難しいです。
センスが問われますし、形式的にコメントを書いている人も多いと思います。

SESだと既存のシステムを改修することも多いですが、何か"意図を持ったコメント"を見ることはとても稀有です。

Javaのお作法に則るとここはStringBuilder使うとこだけど？みたいなのも、

// リテラルの連結のみのため、演算子だけで文字列を操作する.  

とあるだけでとても安心して読むことができます。
まさに「リーダブル」ですよね。

7章 制御フローを読みやすくする

関数から早く返すのはいいことだ。
ネストの深いコードは理解しにくい。ネストが深くなると、読み手は「精神的スタック」に条件をプッシュしなければいけない。

これは特に若手のエンジニアに意識してもらいたいです。
それなりにエンジニア歴の長い人であれば、脳内のRAMがデカいのでなんとかなりますが、駆け出しの方でしたらなかなかしんどいと思います。

めっちゃネストして条件詰め込みまくって結果を変数に詰めてしかも一切returnせずに最後まで持ち回って数千行追いかけた挙げ句やっとreturnする、ってよく見かけます。

脳内のRAMがデカかったらすごいわけでもないですし、それより誰が読んでも疲れないコーディングこそ、保守性に優れていますよね。
コーディングはクリエイティブな作業ですから、いつでも頭をクリアに保つ必要があります。
どうでもいいことに頭を使っても、使わせてもいけません。

比較的、妙齢のエンジニアにとにかく複雑かつ脳内RAMを消費させるコーダーが多いですが、別に私はあなたと記憶力の勝負がしたいんじゃないんですよ。
負けねぇけどな。

9章 変数と読みやすさ

邪魔な変数を削除する。——本章では、結果をすぐに使って、「中間結果」の変数を削除する例を示した。

中間結果を保持する変数は本当に悪です。
前述の7章でも述べたことと同じことが起こってしまう。

また、phpのような(私はphp自体は好きな言語です)暗黙の型定義が行われる言語ではかなりひどいコードになり得ます。
同じ関数なのにあるときはstring、またあるときはboolで返ってくる悪の権化のような関数が作れてしまいます。

なので、類似した処理を見つけたら関数化するのはとてもオススメですが、fatになり過ぎないように注意しないといけません。
なぜかはわかりませんが、fatな関数を見つけるとゴミ箱のように追加実装されてどんどんfatが加速するのです。

保守性を保つことは、エントロピーの増大との戦いなのです。

11章 一度に1つのことを

読みにくいコードがあれば、そこで行われているタスクをすべて列挙する。そこには別の関数（やクラス）に分割できるタスクがあるだろう。

これも、保守性の高いコードにするために大変大事な要素です。
一つの機能、一つのクラス、一つのメソッドの責務は最小に留めなければいけません。

複雑な機能を1つ開発するより、簡単な機能を5つ開発する方が楽です。

だって、1つの機能がとても複雑だったら、大事なハイスキルエンジニアをずっと張り付かせて開発しないといけません。

でも、簡単な機能5つだったら、それなり(失礼!)のエンジニアでも開発できるでしょうし、シンプルであればあるほど"計算しやすい"です。
見積もりの精度も上がります。

テストフェーズに入ったらマンパワーで押し切ることも容易になるでしょう。
シンプルであることは良いことです。

さいごに

大切にしている本なので、読み終わったのは数週間前なのになかなか整理できませんでした。
新米エンジニアに是非読んでほしいです。
他にもたくさんの本を先輩エンジニアに勧められると思いますが、これを読んでからの方がいいです！

何かの言語に特化した内容ではなく、一般化された普遍的な内容ですので、javaの勉強とか個別の勉強よりも先に読んで頂きたいです。

テクニック以前に、とにかく"リーダブル"であることが素晴らしいのです。

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

Amazon 楽天市場

↓こちらもどうぞ↓

www.rptrryo.com