「読みやすいコードのポイントとは / リーダブルコードを読んだ」に関しての考えをまとめました。

リーダブルコードの構成

リーダブルコードの各章の表題と、中身についての要約は次の通り。それぞれ異なるアプローチで「読みやすいコード」を作っている。

１章：表面上の改善

「関数や変数の命名方法」「社内風土の準拠」「コメントアウト」についてのテクニック

２章：ルールとロジックの単純化

主に条件節やループ処理などにおける、「ネストを浅くする方法」「DRYに準拠した類似処理の関数化」についてのテクニック

３章：コードの再構成

複雑なロジックにおける「構造」の組み立て方のテクニック

コードの再構成についてのテクニック

今回は、特に「３章：コードの再構成」について気になる箇所が多くあった。「意識しなければ、気づくとこのような読みにくいコードになってしまう」というケースによく出くわしていたからだ。

１章の表面上の改善や、２章のルールとロジックの単純化についてはある程度は理解しているつもりだし、気づくことができるケースも多い（まだまだ完ぺきではないけど・・・）しかしコードの構成については、まだまだだった。昔の人が「木を見て森を見ず」という言葉を残しているが、コードを書いている状態では、「動けば問題ない」と思ってしまい、全体像がおろそかになってしまうことがよくある。冷静になるとだめだとわかっているのに、当事者になると視野が狭くなってしまう・・・・。そういう意味でも個々の章は刺さった。簡単にまとめる。

１．無関係な下位問題を抽出する。

その関数でスコープされるべきではない要素に関しては切り分けてしまうということ。

たとえば、findClosetLocation()関数にて、緯度と経度の計算方法は、無関係な下位問題なので関数に切り分けるし、名前とurlをDBに保存する関数にて、名前からurl名を取得できるように加工する行為は、下位問題になる。

とはいえ、関数への切り分けは、わずかに読みにくさも上がってしまう。トレードオフ。

また、ケントベックの「Small Talk Best Practice Pattern」によると、「メソッド内聞の処理は同じ抽象度のレベルになるようにする」の原則がある。これもこのルールに即している。

２・関数内で同じ役割の処理を分散させない

「一度に一つのことを」の章によると、ばらばらと呼び出しが行われているものを、同じ領域で行う「デフラグ」行為が必要とのこと。すべての関数において、単一責務の法則を設けるのではなく「ブロック」として考えるとよいらしい。

３．作りたい関数の要約を口に出す。

「コードに思いを込める」の章によると、関数の要約を口に出すことで、人間の思考の同じようにコードを書くことができるとのこと。

これにより、上位の目標の検出も容易になる。つまり「作りたい関数を一言で伝えることで、無関係な下位問題が明確になり、処理の流れも一貫性をもたらす目安が生まれる」とのこと。優先順位の初めは、まずこれより始めよって感じかな。

まとめ

まずは、「作りたい関数の要約を口に出す」ところからはじめようかな

読みやすいコードのポイントとは / リーダブルコードを読んだ

目次