search
LoginSignup
2

More than 3 years have passed since last update.

posted at

updated at

Readable Code を読む - 第3部と第4部 -

Readable Code を読む

今までほぼ我流でコーディングしてきたので,ずっとどうにかしたいと思っていました.
そんなときに,O'REILLYの Readable Code を奨めてもらったので,読んで自分用にまとめてみようと思います.

今回の内容は,第3部と第4部です.

はじめに・第1章はこちら
第1部と第2部はこちら
第3部と第4部はこちら

本書は次のリンク先等で入手できます.
Readable Code

第3部 コードの再構成

コードを大きく変更する技法を紹介.

  • 大きな問題を小さな問題に分割
    • 一度にひとつのことをやる
    • プログラムの主目的と関係のない「無関係の下位問題」を抽出して,処理を分ける
  • 最初にコードを言葉で説明する
    • 具体的な実装方法ではなく,「そもそも何をしようとしているのか」など

10章 無関係の下位問題を抽出する

汎用コード(使い回せるコード)を分離すると読みやすくなる.
因数分解みたいな感じ.共通の処理はまとめた方がよい.

  • ユーティリティコード(汎用コード)の利用
    • ひとまとまりの手続き的な処理を関数化
    • 他でも使いまわせる
    • ユニットテストも可能
    • 部分的な改善を一気に行うことが可能
  • ユーティリティコードをディレクトリ(e.g. util/)にまとめる
    • コードが独立しているため管理しやすい
  • ラッパーして使いやすくするのも良し
  • 細かく関数化しすぎるとかえって読みにくい

11章 一度に1つのことを

  • コードが行なっている「タスク」をすべて列挙する
  • タスクをできるだけ異なる関数に分割する

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

おばあちゃんがわかるように説明できなければ,本当に理解したとは言えない
[アルバート・アインシュタイン]

  • コードの動作を簡単な言葉で誰でも分かるように説明する(コメントなど)
  • 説明の中で使っているキーワードフレーズに注目する
  • 説明に合わせてコードを書く

「簡単な言葉で説明」してみると良い.
言葉にできないとき,それは自分の理解が明確でないときである.

13章 短いコードを書く

自分で書いたコードは,すべての行をテストして保守すること
「欠かせない機能は何か?」と自問自答する(けっこういらない機能を作ってしまっている)

  • ライブラリの再利用
  • 機能の削除
    • 未使用のコードを削除(消したくない気持ちは分かる)
  • 問題の簡略化
    • 簡単な問題に置き換えられないか
  • 重複するコードを削除
    • 汎用的なユーティリティコードを作成
  • プロジェクトをサブプロジェクトに分割
  • 標準ライブラリを使用する
    • できそうなことを雰囲気でつかんでおく
    • 自分のコードより標準ライブラリのほうが信頼できる

第4部 選抜テーマ

  • 効果的で読みやすいテストの書き方
  • 特定用途のデータ構造の設計と実装

14章 テストと読みやすさ

  • 大切な詳細は目立つようにする
    • 大切ではない詳細はユーザから隠す
    • テストの本質ではないコードは関数などを使ってまとめる
  • 良いassert()を使う
    • エラーの原因を表示してあげるなど
    • 手作りのエラーメッセージも良い
  • コードを完全にテストする最も単純な入力値の組合せを選択する
  • 1つの機能に複数のテスト
  • テストの機能に名前をつける
    • テスト関数の名前はコメントと思え(多少長くても気にしない)
    • test_<関数名>()
    • test_<関数名>_<状況>()
  • テスティングフレームワークの利用
    • ヘルパー関数の利用(テストの関数化)
    • e.g. check_<チェック内容>(): assert()を利用しているヘルパー関数の名前の付け方
  • テストを意識したコードを書く
    • どうやって評価するか,考えながらコーディング
  • カバレッジ90%を目指す(100%は現実的に難しい)
    • 作っている製品の特性による
    • 安全が重要な製品はテストに集中する必要がある

NOTE:
テスト容易性の低いコードの特性とそこから生じる設計の問題 (p194)
テスト容易性の高いコードの特性とそこから生じる設計の利点 (p195)

今回のまとめ

今後コーディングするにあたって,非常に参考になった本でした.コーディングする前に,このメモを何度も読むことになりそうです.
この本のテクニックを念頭において,過去に自分が書いたコードをリファクタリングしてみるのも力がつきそうな気がします.

読みやすいコードを書いて、自分が書いたコードを忘れてしまっても問題ないようにして欲しい。読みやすいコードを書こう。忘れてもいいコードを書こう。

「自分が書いたコードってどのくらい覚えているんですか?」
「ほとんど覚えていないですよ」
「直すときどうするんですか?」
「忘れても見たら簡単にわかるように書いておくんですよ」

p231から引用
[ 須藤 功平 氏 ]

こういう考え方,好きです.

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
2