Open4

「Clean Code アジャイルソフトウェア達人の技」要約メモ

yukiyuki

序章

  • Clean Code : きれいで読みやすいコードを書くための手法や考え方などを紹介
  • この本は大きく 3 パートに分かれている
    • クリーンコードを書くための原則・パターン・実践についての解説
    • いくつかのケーススタディ
    • ケーススタディを作成したときに集まった経験則まとめ
yukiyuki

第1章 クリーンコード

この本では良いコードと悪いコードが判別でき、良いコードを書く方法を知り、悪いコードを良いコードに変える方法を知れるよ

  • コードはいずれ書く必要がなくなるだとかモデルとか要件について関心を払うべきと言われてるけど、コードは要件の詳細を実装するのだからコード自体がなくなることは無いよ
  • コード汚いと会社の廃業まで追い込まれるケースもあったよ
  • コードが汚いと生産性が落ちていくよ
  • 運用途中でもリニューアルするケースがあって、その場合は新規構築チームと既存システムの運用チームで別れて競争状態となる
    • 新規構築は既存のシステムへ追加された機能も適宜追加していかなくてはいけなくて大変だよ
  • 管理側からの無理なスケジュールで無理やりコードを書くと徐々にひどい状態になっていくので、プロのプログラマであるならば管理側に対して屈服せずに対応しようよ
  • コードを常にきれいにしておくこが納期を守ることになるよ
  • ボーイスカウトの規則を意識しよ
    • 「自分が書く前よりもコードをきれいにする」
yukiyuki

第2章 意味のある名前

ソフトウェアには変数・関数・引数・クラス・パッケージ・ファイル・ディレクトリなど様々なところで名前をつけるので、わかりやすいようにいくつかのルールを紹介するよ

  • コード上で何が行われているか理解できるように意図が明確な名前をつける
  • 省略語などはなるべく使わずに間違えた情報をコードに入れないようにする
  • 同一スコープ内では2つのものに同じ名前をつけれないからといって、片方の変数名にマジックナンバーをつけたり適当な文字をつけずに意味のある名前をつける
  • 名前は脳内ですぐ理解できるように発音可能な単語にする
  • 1文字や数値定数などは検索では引っかかりにくいので、検索しやすい名前をつける
  • 型やスコープの情報を変数名や関数名に含むエンコーディングは避ける
    • _privateMember、i_value のようなの
  • ハンガリアン記法は避ける
    • numCount みたいに変数名の最初に型情報などの prefix をつける記法をしようしない
    • 型が変わったら変数名を変更しなくてはいけなくなる
  • メンバー変数を表す prefix はつけない
  • インターフェースの名前の先頭に I をつけて命名しない
    • 情報過多となるしインターフェースであることを意識させるべきではない
  • メンタルマッピングは避ける
    • 「d は data のことだ」と脳内変換をしない（他の人はわからない）
    • ループ処理で i, j, k はよく使われるが、この場合はスコープがかなり狭いので問題ない
  • クラス名は名詞にする
  • メソッド名は動詞・動詞句にする
  • 俗語やジョークを交えた名前をつけない
  • 同じコンセプトには同じ名前をつける
    • 例えば取得系を get としている場合 Class によって変えずシステムで統一する
  • 1つの単語を2つの目的で使用しない
    • add という単語のシグネチャが違うメソッドが存在すると、単語が2つの目的として存在してしまっているので、もう一つは append などのメソッド名とする
  • 解決領域の用語の使用
    • CS の用語・アルゴリズムの名前・パターンの名前・数学用語などを使用するのは問題ないが、全てに対していちいち業務用語を付ける必要はない
  • 問題領域の用語の使用
    • 問題領域の概念を扱うのであれば、業務用語から名前をつける
  • 意味のある文脈を加える
    • 単語単体だけだと文脈が分かりづらい変数名があるときは、クラスや名前空間を使用する
    • firstName, lastName, street, houseNumber, city, state, zipcode という変数があればこれらを合わせると住所ということがわかるが、例えば firstName をどこかのメソッドで使われてたとすると何の名前かが分かりづらくなる
    • Address クラスに移して住所の名前と文脈がわかりやすいようにする
    • 最終手段としては addFirstName のように prefix をつける手段もある
  • 根拠のない文脈を与えない
    • 例えば、システムの名前をすべてのクラス名につけるなど、必要以上に文脈を名前に付け加えない
    • 長い名前よりも意味が明確である短い名前のほうが優れている
  • 既存の実装に対しても臆せず適した名前に変更する
    • どうせ自分でも内容は忘れるので、未来の自分や他の人に向けて名前をみれば内容がわかるような命名にする