リーダブルコード読書メモ～その６～

こちらの続きです。11章、12章、13章を見ていきます。

hatek47320.hatenablog.com

これらの章は、割と当然のことをケーススタディを用いてどうする？ということを説明している感じです。 そのため「読書メモ」としてはだいぶあっさり目です。（当然のことができないから困るんですけどねｗ）

11章では「一度に複数のことをしない」という点でコードを変えていきます。

11章

  • コードは一つずつタスクを行うようにする

    • ざっくりでいいので、コードが何をするかを列挙する。
    • タスクをできる限り異なるメソッドに分ける

  • タスクを小さくする

  • 投票ボタンがあって、UPボタンとDOWNボタンでスコアが変わる、という機能を考える

    • 投票前後のスコアを保持して、UPかDOWNかにより、スコアを増減させる、というちょっと複雑そうなロジック。一つのメソッドで実現するのはわかりにくそう。
    • やりたいことは「前後のスコアを数値にパース」「スコア更新」だけであるので、これら二つのメソッドをそれぞれ作ればいい

  • オブジェクトを抽出する

    • 四つのデータディクショナリから文字列を二つ取り出し、結合するケースを考える。
      • 四つの中からどの文字列を結合するかは、条件に従う（書籍ではこの辺ちゃんと書いているが、書くの面倒なので略）
      • ただし、結合される文字列が存在しない場合もあり、その場合はデフォルト値とする
    • この場合「データディクショナリの値を抽出」「どの文字列を結合するかの判定」「文字列の代入。なければデフォルト」「文字列を結合する」というタスクに分かれるのでそれぞれで関数を分ける
    • if文がごちゃごちゃしてきたら、並べ替えたりして簡易にならないか検討してみる（ドモルガンの法則とか役に立つのではと思います）

見にくいコードに対して「このコードは何をしているのか」を列挙して、その単位でまとめるといいことがあるよ、みたいな感じだったと思います。 11章はそこまで言いたいことが多くなく、同じテーマをケーススタディ的に「こういう時はこうする」みたいな感じに書いているように見えました。なのでまとめもあっさり目です。

12章では、コードをより簡単に書く方法について触れています。

12章

自分よりも知識が少ない人がわかるように物事を説明できるようになるべき。ソースコードも一緒。 * コードの動作を簡単な言葉で同僚に説明する * 説明時のキーワードに注目 * 説明に合わせてコードを書く

えーっと12章はこれくらいです。変にコードを意識してわかりにくいロジック、コードにするのではなく、言葉で説明してみる、それをコードにする、ということを重要視する感じでしょうか。その説明をケーススタディで色々していた印象でした。

次は13章です。

端的に言うと、コードを書くな、ということです。バグをなくすためにはコードを書かないこと、というのは有名？な話ですが、それに通ずる話ですね。

  • 要求分析

    • 言われたことをそのまま実装するのではなく、要求をしっかり分析して、実装する、しないをわけること

  • コードは小さく保つ

    • なるべく汎用的な共通コードを使う。ＯＳや言語のライブラリに任せられる場合はできる限りそうする。
    • 未使用のコードや不要な機能は削除する
    • プロジェクトをサブプロジェクトに分ける
    • コードは軽量にする（おそらく使いまわせるようにする、とかシンプルに保つ、ということだと思います。）

終わりに

11～13章と一気に駆け抜けました。普通のプログラマならああそうだよね、というような話ばかりだったので、これまでと比べると少々薄く、真新しいことはなかったのではと思います。 ただ、当然のことをやるのは案外難しかったりするので、ＰＲ出すときに最終チェックの観点として押さえておきたいですね。