「プリンシプル オブ プログラミング」 レビュー

書籍について

タイトル プリンシプル オブ プログラミング
3年目までにみにつけたい一生役立つ101の原則原理
著者 上田 勲
発行日 2016/03/29
ページ数 303ページ
価格 2200円
Amazon https://www.amazon.co.jp/dp/4798046140/
読了日 2017/02/14

感想とかメモ

  • プリンシプル = 原則/原理
  • 良いコード(特に保守性、拡張性の優れた)コードを書くための原則、原理を集約した一冊
  • サブタイトルに「3年目まで」と書かれていたり、帯に「めざせ、脱・初心者」とアオリ文が書いてあったり、一件初心者向けの本にも見られるが、全体的に内容は難しめ
  • まるで洋書を訳したかのような言葉の選び方や言い回しが多く、それに加えて内容も難しいため、気軽に読むのが難しい項目も少なからずあった
  • 「3年目」とか関係なく、全てのプログラマが持つべき考え方が詰まっている
  • 逆に「3年目」程度では理解できない内容も多いため、経験を重ねる度に読み返すことで自分の立ち位置が把握できそう
  • 具体的なコードは一切掲載されていない。著者曰く「具体的な場面でしか使えないものと誤解されないように」とのことだが、具体的なコードが無いとそれはそれでイメージができない項目も多かった(コードは自分で書いてみようということか)
  • 当然特定の言語、環境に依存した内容ではない
  • 全体的にテストが整備されてる前提だと感じた。テストが整備されていない時点でキレイなコードを書くのは不可能なのか

要約とか備忘録

本項では、本書に記された101の原則・原理のうち、個人的に気に入ったものについて要約及び個人的な考えなどを整理する。基本的に最小限しか書いていないが、ページ数も併記しているので、気になった所だけでも読んでみよう。

1.2 コードは設計書である(P23)

  • 製造業に置ける「製造」は、システム開発におけるコーディングであるという考えは間違え
  • システムはソースコードという「設計図」に基づいて、コンパイラやビルドツールが「製造」する
  • 故にプログラミングは仕様を符号化する作業ではなく、設計という創造的行為である

1.3 コードは必ず変更される(P26)

  • 一度書いて終わるコードなどまず無い
  • コードが変更されるという事実を、コーディングする上での最重要事項として認識する必要がある。
  • 変更されることを意識すれば変更に強いコードが書ける
  • 変更に強いということは変更しやすいということであり、それは「読みやすいコード」であることだ。

2.4 PIE(意図を表現してプログラミングせよ)(P43)

  • 前提として、ソースコードはコンピュータが読むものではなく人間が読むものである
  • ソースコードは書く時間よりも読む時間のほうが圧倒的に長い
  • 一人でコードを書いたとしても、書いた直後時自ら読むことは避けられない。そしてそれは最早他人である。
  • ソースコードは、What/Howは記述されているが、Whyは記述されていない
  • つまりコメントに必要なのはWhatでもHowでも無く、Whyなのだ
  • WhatやHowをコメントで記述しなければ理解できないソースコードは設計、実装に誤りがある

2.7 名前重要(P57)

  • プログラミングにおいて、「命名」は最重要課題の一つである。
  • 名前はコードを読む人にとってのUIである
  • 名前が適切であれば、コードを読む人は名前から内容を推測することで、内容を読まずともコードリーディングを進めることができる。
  • 逆に名前が曖昧であったり、意味を成していない場合、内容まで追わなければコード全体を把握することができない。
  • 適切な名前がすぐに思いつかないのであれば、それは設計、実装に誤りがある

3.6 繰り返しの最小化(P73)

  • コード中に同じコードが繰り返し登場してはならない
  • 繰り返しのコードは、修正範囲を誇大化させる
  • さらに、繰り返し存在するコードそれぞれに同じ修正を適用して問題ないかの判断も必要になる
  • 繰り返しを排除するためには、コードを小さい部分に分割することを意識付ける。大きなコードは繰り返しが発生しても気づきにくくなるからだ

単一責任の原則(P79)

  • モジュールを変更する理由は2つ以上あってはならない
  • 理由が複数あるということは、そのモジュールが複数の責任(役割)を持っているからだ
  • モジュールは1つの1つのみの責任を持たせなければならない
  • 何故なら、2つの責任がある場合、片方の修正のためにもう片方が影響を受ける可能性があるからだ

3.18 ポリシーと実装の分離(P93)

  • ポリシー = ソフトウェアの前提に依存するビジネスロジックなど
  • 実装(メカニズム) = ソフトウェアに依存しない、再利用が可能なロジック
  • モジュール内でポリシーと実装が混在していると、ポリシーの変更に実装が影響を受けてしまうため
  • ポリシーが独立したモジュールである場合、それは再利用可能であり、単体テストも行いやすい良いモジュールである

3.20 参照の一点性(P97)

  • 定義は極力一度きりにする(再代入しない)
  • ロジックの流れを追うごとに、変数の中身が変わることは、コードを読む上での脳への負荷となりやすい
  • 単一代入を強制する言語、アーキテクチャも多く存在する

3.39 明確性の原則(P132)

  • コードの解読を3回以上繰り返してはいけない
  • 1回目は仕方ない
  • 2回目解読する機会が来たら、その場で改善しなければならない
  • 3回目を迎えることのないように改善する

3.44 透明性の原則(P132)

  • 随所にデバッグを簡単に行うための仕組みを入れておく
  • プログラマがその気になれば、どんなデバッグ情報もすぐに出せるようにする
  • 本番コードにデバッグ機能を搭載することを躊躇しない(もちろんON/OFFは切替可能に)

3.52 最適化の原則(P154)

  • 「速いコード」より「正しいコード」
  • 早い段階で「速いコード」を書こうとすると破綻する
  • まずは正しく読みやすいコード、テストを書き、ボトルネックと認められた場合に手を加える

3.58 即行プロトタイプ(P164)

  • できるだけ早くプロトタイプの開発に着手する
  • どんなに仕様を詰めても、ドキュメントを整備しても、動くものを見たら全てが変わる

3.62 シェルスクリプト活用(P173)

  • 繰り返し行なっている操作は可能な限り自動化する
  • シェルスクリプトは移植性が高い
  • シェルスクリプトはプラットフォームに依存しにくい
  • シェルスクリプトは他のソフトウェアと結合しやすい

4.5 コードの臭い(P205)

  • コードの臭い = コードから見られる理解しにくさ、修正しにくさ、拡張子に草
  • プログラマはコードの臭いに敏感である必要がある
  • いくら良いコードが書けるようになっても、悪いコードを見つける力が無ければリファクタリングはできない

5.1 プログラマの3代美徳(P214)

  • 怠慢
  • 短気
  • 傲慢

5.2 ボーイスカウトの規則(P218)

  • ボーイスカウトの規則 = ボーイスカウトは、自分のいた場所を自分が来る前よりも綺麗にして帰らなければならない
  • プログラマがソースコードを修正する時、その周辺のコードも綺麗にする必要がある

5.4 エゴレスプログラミング(P226)

  • 能力、年齢、立場に関係なく、皆でより良い物を作ることに価値を置く
  • コードを私物化せず、定期的に同僚にコードを見せたり、同僚のコードを見たりする

6.5 ラバーダッキング(P253)

  • 自分のコードについて声に出して説明すること
  • 説明相手は最悪無機物(ラバーダッキング=ゴムのアヒル)でも良い
  • 声に出して説明することで、自分が自分のコードをどれだけ理解できるかを図ることができる

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です