書籍プリンシプルオブプログラミング第2章まとめ

原則 ~プログラミングのガイドライン~

2.1 KISS

KISS：シンプルに保つ

コードを書く際は、「単純性」「簡潔性」を最優先にすべき

コードの可読性を高めることによって、修正時の読み返し時間を短縮させられる。また、プログラマ同士「コードを見れば分かる」という状況を作り出せることで開発速度を保てる。

シンプルにする上でやってはいけないこと

新しく覚えた技術を強引に使用

コードは頭の良さやテクニックをアピールする場所ではない。あくまでシンプルに動作させることに重点を置く

将来必要になりそうなコード

現在必要な分だけを記述する。将来必要だと思っても不必要になることもある(結果的に無駄)

勝手に要件を加える

要件を決めるのは「ユーザ」、プログラマは余計なことをしてリスクを増やさない。

KISSの適用範囲

内部のコードだけでなく、GUIや機能などの外部インターフェースもシンプルに保つことは、使いやすいソフトウェアの誕生に貢献する。

意識すべきこと

今自分の書いているコードは本当に必要なのか
もっとも単純な物が正しい

2.2 DRY

DRY：繰り返さない

コードのコピペ厳禁

同じコードが複数の場所にばらまかれてしまうため、以下のような作業をするのが困難になる

読み返し

単純にコードの量が多くなるため、無駄に時間がかかる

修正

同じ修正を複数の箇所を行うため、手間や見落としが発生する可能性がある

テスト

重複しているコードは、大抵の場合レガシーコードであるためテストが無く、不具合が発生する可能性がある

対処法

コードを抽象化する

共通の処理をメソッドやモジュール化することで修正を一括で行なったり、データに名前のある定数を定義して扱いやすくするといったこと

コードの量を減らせる
ロジックやデータに名前(定数)が付いているため、コードを直感的に読める
コードの修正を一箇所で行えるため、品質の向上や開発時間を短縮できる
継承などを行うことでクラスを再利用できる(作り直すための時間を減らせる)

現在のコードをこういった形に変更するのは時間もかかるし面倒な作業だが、長い目で見ると後々有利になってくるのでなるべく行うべき。

DRYの適用範囲

コーディングのときだけでなく、ソフトウェア開発のときにも繰り返しは割けるべきである。例えば、プログラムの動作テストを自動化することで、人が行なっていた時の「手間」「ミス」「時間」といった問題点を全て解消できる。

DRYとプログラミング言語

プログラミング技術やその設計手法の多くは、重複を排除することを目的に含んでいる。また、技術や手法を学ぶ際は、やり方だけなく「何故こうしているのか」といった目的にフォーカスすることで理解を早められる。

やむを得ないDRY違反

異なる抽象化スタイルの境界で同じ情報の重複が起きてしまう場合もある。そういった場合は、一箇所に情報を全て集約した上で、そこから他の情報を動的に生成する仕組みにするといった工夫が必要になる。

DRYに関連する言葉

WET

DRYの対義語

OFOP

DB設計における「一つの情報は一つの場所へ」という原則を示す。同じ情報が複数のテーブルやフィールドに存在していると冗長なため正規化が必須。

OAOO

DRYと同じ意味だがプログラミングのみに適用される。「コードの重複」「不必要なコード」を排除することを強調。

レガシーコード

スパゲッティコード的なものだけでなく、テストの無いコードに対しても言われる。(仮にどんなに綺麗なコードでも)
コードに対しては必ずテストを行うべきで、テストの無いコードを見つけたらまずテストをすべき

2.3 YAGNI

YAGNI：それはきっと必要にならない

コードは必要最低限にする

緊急時に備えて機能を用意しても大抵利用されず実装時間の無駄なため、コードの機能は必要最低限に抑えること。

(おまけに可読性が下がり保守に時間がかかるため、もはや邪魔)

コードは今必要なものだけに抑える

まず最低限の機能だけを実装する(汎用性よりも単純性)

これはコードだけでなく、開発全体で適用される。

DTSTTCPW

「上手くいく手段のうち、一番シンプルな手段を選べ」

「まず単純ことをして、変更が必要なら追加コストを払う」が理想。複雑なことは必要なときに実装すればいい。

先のことをあまり考えすぎない、必要最低限の機能を常に念頭に置くべきである。

2.4 PIE

PIE：意図を表現してプログラミングせよ

コードの意図を伝える

コードは人が読むものということをを第一に考え、分かりやすく書く。 (ソフトウェアの仕様を完全に把握するには、仕様書以上にコードを読む必要があるから)

読みやすさが最優先

コードは書かれる機会よりも読まれる機会の方が圧倒的に多いため、書くのに多少手間がかかっても読みやすい方が全体の効率は上がる。

モグラたたき開発は避ける

モグラたたきのように、あちこちにバグが潜むようなコードを書かないようにする。多少時間がかかっても、可読性や品質が高く障害の無いコードを書いた方が長期的な利益に繋がる。

コメントを書くこと

コードだけでは「何故その処理をしているのか」などの伝えられないことがあるため、コメントは積極的に活用してコミュニケーションを取る。

文芸的プログラミング

コードとドキュメントを編み込んで記述する方法 (コンパイラに通すコードとしても、人が読むドキュメントとしても扱えるようにする)

特徴

コードの説明と正当性を記述しながらプログラミングを進めるため、コードについて客観的に考えられる。
コードと説明が近接した位置に記述されるため、修正がしやすい
コードベース全体でドキュメントの一意性を保証できる
アルゴリズムの説明や設計上の決定の根拠などといった、通常のコメントでは解説しきれないこともコードに記述される

2.5 SLAP

SLAP：抽象レベルの統一

コードのレベルを合わせる

機能(関数)を抽象化する際に、同じ階層にある機能同士の抽象化レベルを統一することで、書籍の目次のように各機能を参照しやすくなる。また、関数だけでなくモジュールにも適用できる。

2.6 OCP

OCP：開放・閉鎖の原則

コードの変更を波及させない

「拡張に対し開放的」と「修正に対し閉鎖的」の2つを満たせるようコードを設計することで、既存のコードに影響を与えずに機能の拡張を行える。ある程度変更が行われそうな部分に適用すべき。

2.7 名前重要

命名は最重要課題

クラスや関数に適切な命名が行われていないということは、プログラマがその要素を理解できていないことの裏付け。

コードは読む人のUI

関数名やクラス名から機能を推測出来ない場合、内部の構造を確認しなければならない。さらにそれを保守の度に行わなければならないため大きな負債となる。

意識すべきこと

名前は「短いコメント」だと考えて、伝えるべき情報をしっかり含むこと
他の名前と誤解されないように一貫性を持たせる
「効果」「目的」を説明する
現実の会話で発音できるものにする