【プリンシプルオブプログラミング】法則
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
法則 〜プログラミングのアンチパターン〜
ブルックスの法則
要員追加は「火に油」。
スケジュールが遅れているソフトウェア開発プロジェクトにおいて、遅れを取り戻すために、後半に人を追加すると、逆にさらなる遅延を招く。
【理由】
- 依存関係によるオーバーヘッドが発生する
- 教育に時間を取られる
【やるべきこと】
スケジュールが遅れた場合、リスケジュールする。
その際は、ユーザーと調整しながら、機能に優先度を付けて、段階的にリリースする。
コンウェイの法則
ソフトウェアの構成、つまり「アーキテクチャ」は、それを作った「組織」を反映する。
【意識すべきこと】
よいアーキテクチャを設計して、そのアーキテクチャに組織を合わせるようにすべき。
割れた窓の法則
たった一枚の割れた窓を放置すると、建物全体に対する深刻な破損が起こり始める。
つまり、「悪い設計」「間違った意思決定」「悪いコード」を放置すると、それがどんなに小さなものでも、ソフトウェア全体をごく短期間で腐敗させることになる。
【意識すべきこと】
コードのよくない部分をそのままにせず、発見と同時に修復する。
エントロピーの法則
エントロピーとは、物理学の用語で、「無秩序な度合い」を表すもの。
コードは自然に任せると、限界を超えるまで無秩序さが増大する。いわば「腐ったコード」になっていく。
【意識すべきこと】
コード腐敗の兆候をつかむ。
- 硬さ：変更の難しさ
- 脆さ：たった1つの変更によって、他の多くの部分が壊れてしまう度合い
- 移植性のなさ：他の環境への移植のしにくさ
- 扱いにくさ：設計構造の柔軟性のなさ
- コードの扱いにくさ
- 開発環境の扱いにくさ
- 複雑さ：「不必要な」要素の多さ
- 繰り返し：同じようなコードが何度も繰り返し現れること
- 不透明さ：コードのわかりにくさ
80-10-10の法則
- 80%：ユーザーが求めることを驚くほど短時間で実現することができる
- 10%：実現は可能だが相当な努力が必要となる
- 10%：完全に実現が不可能。ツールを使わない形で、泥臭い形で、要求を満たすことになる
【意識すべきこと】
ソフトウェア開発において、万能薬はないことを認識する。
ツールの使用は適材適所。
【その他】
「80:20の法則」：全体の数値の8割は、全体を構成するうちの2割の要素が生み出しているという、自然や社会に多く見られる現象のこと。
ジョシュアツリーの法則
人は名前を知った途端、それが見えるようになる。逆に、名前がなければ（知らなければ）、それが見えない。つまり、名前を知ることで存在を知る。
【やるべきこと】
名前を付け、言葉を作り、チームで共有する。
これには、「ユビキタス言語」を使用する。
ユビキタス言語とは、その問題領域の各要素を正確に表現する、チームの共通言語のこと。
セカンドシステム症候群
2番目のバージョンには、機能を盛り込みすぎてしまい、品質が悪く、機能の使い勝手も悪くなる傾向がある。
【意識すべきこと】
プログラマは、自制心を働かせ、「多機能主義」にならないようにする。
改めてユーザーを明確に定義し、イメージすること。
- ユーザーは、誰なのか？
- ユーザーは、何を必要としているか？
- ユーザーは、何が必要だと考えているか？
- ユーザーは、何を望んでいるか？
車輪の再発明
ある機能について、既にそれを実現しているコードやライブラリがあるのに、自分で改めて同じ機能をプログラミングしてしまうことがある。
【２つのパターン】
- 車輪を知らない：知識不足・勉強不足によるもの。
- 車輪を作りたい：欲求によるもの。つまり、確信犯の再発明。
【意識すべきこと】
車輪の再発明を避け、本来やるべき作業に注力する。
コードを書く前に必ず以下をチェックする。
ただし、ビジネス目的・学習目的であれば話は別。
ヤクの毛刈り
問題を取り組んでいる時、ある問題を解こうと思ったら別の問題が出てきて、なかなか本体、つまり大元の問題（の解決）にたどり着かないことがある。問題を解こうと思ったら、さらに別の問題が出てきて、ということが延々と続く。
この状態が長いと、もはや何を解決しようとしていたか、元の問題を忘れてしまうことすらある。
【意識すべきこと】
ヤクの毛を刈っている状態に陥っていると感じたら、立ち止まり、そもそも何が目的だったかを思い出す。
「目的からずれている」「時間やコストと見合わない」と認識した場合は、すぐに作業を止めるようにする。おそらく、もう別の道を探した方が、良い結果となるはず。
また、他の人が同じ状態にはまらないよう、その顛末をメンバーに共有する。
【プリンシプルオブプログラミング】手法
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
手法 〜プログラマの道具箱〜
曳光弾
プログラミングにおける「曳光弾」とは、優先的に検証したい部分を、先行的にプログラミングすること。簡易で構わないので、実際の環境下で動作して、確認できる、エンド・ツー・エンドのソフトウェアを作成する。
ここで作成するコードは、フレームワークであり、土台となる。
【メリット】
【やるべきこと】
最初に動作する土台を作る。
土台のコードは最小限に留める。
【プロトタイプとの違い】
- プロトタイプ：ソフトウェアのコンセプトや最終形態についての「理解を検証する」ためのもの。
- 曳光弾：ソフトウェア全体がどのように連携するのかを明らかにする。ユーザーに対して、どのような使い勝手になるのかを提示する。
契約による設計
「契約による設計」とは、関数と、関数を呼び出す側で、互いに「契約」結んでいると見なしてプログラミングすること。
【やるべきこと】
コメントとアサーションで契約する。
【注意点】
- 関数側では、引数の調整を行わない
- 関数側のアサーションを、ユーザーの入力チェックに使用しない
- 関数側では、想定は厳格に、確約は寛容に
防御的プログラミング
関数に不正なデータが渡された時に、それが他の関数のせいであったとしても、被害を受けないよう「防御的な」コードを書いておく。
【考慮すべき点】
- 外部ソースからのデータ入力の値を確認する（「想定内のエラー」を検出）
- 関数の入力引数の値を確認する（「想定外のエラー」を検出）
【意識すべきこと】
「バリケード戦略」を取る。バリケードを構築して、被害を封じ込める。
ドッグフーディング
自分で開発したソフトウェアは、自ら使用するようにする。
人に使ってもらうものなので、自ら率先して「味見」して、その塩梅を確かめる責任がある。
【意識すべきこと】
リリース前に、自分でユーザーのように使う。
ラバーダッキング
プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明する。すると、問題の原因に自ら気付き、自己解決できることがある。
【意識すべきこと】
問題解決が停滞した場合、「誰か」にそれを説明する。
コンテキスト
コンテキストとは、周りの状況や背景のこと。文脈とも言う。
【２つの側面】
- コードの読み書きに利用：コードを書く人と、コードを読む人とのコミュニケーション。
- 思考のツールとして利用：プログラミングは問題解決の作業。
【意識すべきこと】
コードを書く時、コンテキストを先に示すようにする。
【プリンシプルオブプログラミング】習慣
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
習慣 〜プログラマのルーティーン〜
プログラマの３大美徳
プログラマの3大美徳は、できるプログラマの特性を、3つの「美徳」としてまとめたもの。
- 怠慢：全体の労力を減らすために、手間を惜しまない気質。
- 短気：コンピュータがさぼっている時に、怒りを感じる気質。
- 傲慢：神罰が下るほどの、過剰な自尊心を持つ気質。
怠慢
後で皆が楽できるように、今役立つコードを書いてしまう。
【やるべきこと】
繰り返しの仕事を「仕組み化」する。
手作業については、コードを書いて、ツールを作って、自動化する。
短気
コンピュータが十分効率的に働いていなかったり、意図通りに働いていなかったら、ただちにコードを書き直してしまう。
また、今ある問題に留まらず、今後起こりうる問題を想定したコードを書いておく。
【やるべきこと】
起こりうる問題を「想定して」仕事をする。
先回りして、要望が出てきそうな部分を考え、クレームが出る前に対応できるようにする。
傲慢
高いプライドを持ち、人様に対して恥ずかしくないコードを書く。
自分のコードを誰に見られても恥ずかしくないように書く。
【やるべきこと】
人様に対して恥ずかしくない仕事をして、保守していく。
プロ意識を持って、保守を容易にしておく。
ボーイスカウトの規則
ボーイスカウトには、シンプルな規則がある。
「自分のいた場所は、そこを出て行く時、来た時よりもきれいにしなければならない」という規則。
【意識すべきこと】
コードは改良してからコミットする。
パフォーマンスチューニングの箴言
パフォーマンスチューニングとは、速いコードを書くこと。コードの「最適化」とも言われる。
【最適化のルール】
- 行ってはならない
- （エキスパート専用）まだ行ってはならない
【デメリット】
- 可読性の低下
- 品質の低下
- 複雑性の増大
- 保守の阻害
- 環境間の競合
- 作業量の増大
【やるべきこと】
まず「よいコード」を書き、その後、必要に応じてパフォーマンスチューニングを行う。
エゴレスプログラミング
プログラミングにおいては、エゴを捨て去る。
つまり、「うぬぼれ」や「プライド」を捨て、仲間に協力を求めるようにする。自分の書いたコードを、積極的に仲間に見せて、改善点を指摘してもらう。
- 自分自身も間違いを犯すということを理解し、受け入れる
- 書いたコードは、自分自身ではない
- どれほど極めたと思っていても、上には上がいる
- 相談なしに、コードを書き直さない
- 自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って接する
- 世界で唯一変わらないことは、変わるということだけ
- 本当の権威は、地位ではなく、知識から生じる
- 信じるもののために戦う。ただし、負けは潔く受け入れる
- 部屋に籠りきりはいけない
- 「人に優しく、コードに厳しく」して、人ではなくコードを批判する
１歩ずつ少しずつ
プログラミングは、一度に、小さな1つのことを行う。
【意識すべきこと】
一度に複数やらない。
TMTOWTDI
他の人に使用してもらうツールを設計する場合、達成したいことの手段を複数用意する（プログラミング言語やDSLやAPIなど）。
ツール側は複雑になってしまうが、使う側は、多様な場面において、シンプルなコードが書けるようになる。
【意識すべきこと】
選択肢をたくさん用意する。
【プリンシプルオブプログラミング】視点
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
視点 〜プログラマの観る角度〜
６つの視点
- 凝集度
- 結合度
- 直交性
- 可逆性
- コードの臭い
- 技術的負債
凝集度
凝集度とは、モジュールに含まれている機能の純粋さを表す尺度。モジュールを「強さ」を測るもの。
- 暗合的強度：モジュール内の要素間に、特別の関係が認められない。暗合とは「偶然に物事が一致する」という意味。
- 論理的強度：ある機能を抽象的に捉えてまとめたもの。
- 時間的強度：特定の時点（時間）に連続して実行する複数の機能を1つのモジュールにまとめたもの。
- 手順的強度：問題を処理するために関係している複数個の機能のうちの、いくつかを実行する。
- 連絡的強度：基本的に手順的強度の特性を持つ。異なるのは、モジュール内機能間でデータの受け渡し（連絡）をしたり、同じデータを参照する点。
- 情報的強度：特定のデータ構造を扱う複数の機能を、1つのモジュールにまとめたもの。
- 機能的強度：モジュール内のすべての命令が1つの役割（機能）を実行するために関連しあっているモジュール。
【意識すべきこと】
高強度モジュールを目指す。
結合度
結合度とは、モジュール同士の関係の密接さを表す尺度。ある結合の「太さ」を測るもの。
- 内容結合：あるモジュールと他のモジュールが一部を共有するようなモジュールの結合の仕方。
- 共通結合：共通域に定義したデータを、いくつかのモジュールが共同使用するような結合形式。
- 共通域の定義データ：いわゆる「グローバル変数」のこと。
- 外部結合：外部宣言したデータを共有したモジュール間の結合形式。
- 外部宣言した定義：public宣言された変数など。
- 制御結合：呼び出し側のモジュールが、呼び出されるモジュールの制御を指示するデータを、パラメータとして渡す結合形式。
- スタンプ結合：共通域にないデータ構造を、2つのモジュールで受け渡しするような結合形態。
- データ結合：モジュール間のインタフェースとして、スカラ型のデータ要素だけを、パラメータとして受け渡す結合形式。
【意識すべきこと】
低結合モジュールを目指す。
【その他】
- ハイブリッド結合：データ状況に応じて複数の意味を持つ状態。
- 結合の本数と方向：「強さ」「太さ」以外にも「本数」「方向」にも気を配る必要がある。
- べき等性と安全性
- べき等性：ある操作を何回行っても結果が同じこと。
- 安全性：：操作対象の状態を変化させないこと。
直交性
直交は、幾何学において、グラフの座標軸のように直角に交わる2つの線分の性質。
【意識すべきこと】
コードのレイヤー化。
不要な情報は他のモジュールに公開せず、また、他のモジュールの実装を当てにしないコード記述を心がける。
可逆性
可逆とは、ある変化が起こっても、ある条件を加えると元の状態に戻るという性質。
【意識すべきこと】
特定技術に依存しない。
変更に耐えうるため、やり直しができるような設計にする。
コードの臭い
「コードの臭い」とは、コードの中で、理解しにくい、修正しにくい、拡張しにくい、と感じられる部分のこと。この問題点の嫌疑を、不吉な兆候として、怪しいサインとして、「臭い」と呼ぶ。
【意識すべきこと】
「コードの臭い」の兆候を把握する。
「どういう状態が悪臭か」「なぜこれが悪臭なのか」を把握する。
- よく見る
- 長すぎる
- 大きすぎる
- 多すぎる
- 名前が合わない
技術的負債
技術的負債とは、コードにおける「修正しにくい」「理解しにくい」といった、問題のある汚いコード部分のこと。
- 十分に時間があれば、「時間がかかっても、きれいなコード」を選択すべき
- 修正の緊急度が高い場合には、「素早く汚いコード」を選択する場合、それが負債
【意識すべきこと】
問題コードを管理する。
素早く返済するのが一番。
返済の時間がなかった場合は、せめて、その本来書くべきであったコードの設計を、ドキュメントに残しておく。
【プリンシプルオブプログラミング】UNIX哲学
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
思想 〜プログラミングのイデオロギー〜
UNIX哲学
UNIX哲学とは、UNIXの背後にある設計の哲学のことで、いわば「UNIXという考え方」。
９個の定理
小は美なり
小さいものは扱いやすい。
コードを書く時は、小さなものから始めて、それを小さなままに保つ。
一つ1仕事
ソフトウェアがピュアになる。
一つのソフトウェアには、一つの仕事を担当させるようにする。
問題が大きかった場合は、まず、問題を分割する。そして、その小さな問題に対応する、小さなソフトウェアを作る。
即行プロトタイプ
試行錯誤なしでよいものは作れない。
早いプロトタイプ作成によって、リリースを早める。
【メリット】
- 前提の誤りを早期に発見できる
- 要件不備によって手戻りを減らせる
- 早いうちから誤りを取り除く作業を始められる
効率性より移植性
ソフトウェアの価値を持続。
移植性を重視した設計を行う。
ハードウェアに依存する部分と、依存しない部分を切り離した設計を行う。
データはテキスト
テキストファイルは万能型。
ソフトウェアは、各々テキストファイルを入出力するように設計して、ソフトウェア同士の連携を容易にする。
レバレッジ・ソフトウェア
少ない労力で巨大な成果を得る。
機能満載の大きなソフトウェアを書くのではなく、それぞれが単機能で単価値に集中した小さなソフトウェアを作る。
シェルスクリプト活用
梃子（てこ）の効果を増幅する。
シェルスクリプトをグルー言語として使用する。
小さなソフトウェアをシェルスクリプトでつなげて、大きな仕事を成し遂げる。
対話インタフェース回避
ユーザーもマシンもソフトウェアも束縛される。
1つの仕事をして、それを終えたら、コマンドインタプリタに制御を返すようなソフトウェアを作成する。
対話型のインタフェースを初心者向け、慣れている人向け、両方のインタフェースを用意する。
フィルタ化
ソフトウェアとは入出力である。
ソフトウェアは、データを処理するフィルタとして設計する。
【プリンシプルオブプログラミング】UNIX思想
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
思想 〜プログラミングのイデオロギー〜
UNIX思想
UNIX思想とは、UNIX文化の中で育まれた、優れたプログラミングを行うための、経験に基づいた実践的な「技」の集合。
17個の原則
- モジュール化の原則
- 明確性の原則
- 組み立て部品の原則
- 分離の原則
- 単純性の原則
- 倹約の原則
- 透明性の原則
- 安定性の原則
- 表現性の原則
- 驚き最小の原則
- 沈黙の原則
- 修復の原則
- 経済性の原則
- 生成の原則
- 最適化の原則
- 多様性の原則
- 拡張性の原則
モジュール化の原則
モジュールは、そのインタフェースを、余分なものはそぎ落とし、極限まで少なくする。
ソフトウェアは、シンプルなモジュールの集合体として構築する。
明確性の原則
人にわかりやすい、明確なコードを書くようにする。
組み立て部品の原則
テキストストリームを読み書きする、コマンドラインで使用できるソフトウェアを設計する。
分離の原則
安定的な部分と不安定な部分を明確に分けて管理する。
- サービス系アプリケーション
- 「ポリシー」：クライアントからの要求を受け付けるフロントエンド
- 「メカニズム」：実際のサービスを行うバックエンド
- エディタアプリケーション
- 「ポリシー」：拡張可能なユーザーへのインタフェース
- 「メカニズム」：エディタのエンジン
単純性の原則
「もっとも単純で美しい」ことを誉めあう文化を構築する。
- コードが膨れ上がり複雑化することを、きっぱりと拒否する
- 逆に、単純な解決方法を互いに高く評価する
- 大量の機能でソフトウェアを飾り立てることには、反射的に抵抗する
- 逆に、連動しあう小さな部品に分割する方法を探す
倹約の原則
- 小さなコードを書くようにする
- 大きなコードは分割する
- 分割に失敗した時に限り、大きなコードを残すようにする
透明性の原則
デバッグのための機能を、設計の最初の段階から組み込む。
安定性の原則
コードが「透明」「単純」であることを、常に保つようにする。
【行うべきこと】
- コードレビュー
- 特異な入力や極端に大きい入力に耐えられるような検証
表現性の原則
コード上の避けられない複雑さの部分は、データ側に寄せるようにする。
コードを改善していく時も、コードの複雑さをデータの複雑さに切り替えていくことを検討する。
驚き最小の原則
予想通りに動作するようなインタフェースを設計する。
【気を付けるべき点】
- よく似たソフトウェアのインタフェースをモデルにする
- 想定ユーザーの特徴を考慮する
- 伝統に注意を払う
- 「一見似ているが微妙に異なる」ということを避ける
沈黙の原則
表示出力を最小限に抑える。
重要な情報のみ出力して、内部動作の情報を混在しないようにする。
【方針】
- 本当のエラーだけを標準エラー出力に表示して、その他の要求されていないデータはいっさい出力しないようにする
- デバッグの目的で、進行状況についてメッセージを表示したい場合は、冗長モードのスイッチを作り、デフォルトではそれを無効にしておく。
修復の原則
エラーが発生した場合には、できるだけ早い段階で、けたたましく通知するようにする。
ただし、ユーザーの誤った入力や、ソフトウェア自身の実行エラーは、まずは穏便に処理すべき。
それができない時、ただちに、できる限り簡単に障害を診断できるようなエラーを起こすようにする。
経済性の原則
- 開発環境のためのハードウェアやソフトウェアに投資する。開発効率が上がり、ストレスは下がるので、生産性や品質が格段に向上する
- ルールや制約は、施行後にバランスを調整する
- いったん作るルールは叩き台として考え、運用後、プログラマの意見を聞くようにする
- 開発に支障が出ているのであれば、「これだけは最低限譲れない」というところまで譲歩する
生成の原則
コードを生成するコード、つまり、コードジェネレータを適材適所で作成する。
特に、繰り返しが多く、定型的なコードは、コードジェネレータの対象とする。
最適化の原則
まず動かし、正しくしてから、速くする。
多様性の原則
よりよいやり方を求め続ける。
プログラミングに対して、「唯一の正しい方法がある」という喧伝については、きちんと「不信感」を持って接するようにする。
拡張性の原則
プラガブル（接続可能）になるように設計し、それを明示する。
機能を簡単に追加できるようなコードを書く。
【プリンシプルオブプログラミング】７つの設計原理
目次
はじめに
この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者: 上田勲
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/23
- メディア: 単行本
- この商品を含むブログ (11件) を見る
思想 〜プログラミングのイデオロギー〜
７つの設計原理
７つの設計原理とは、障害を作り込まないために考慮すべき、コード構造上の７つの核心観点のこと。
「どうしたら開発時に障害を作り込まないようにできたか」という観点から根本原因を分析して、その結果、導かれた原理。
- 単純原理
- 同型原理
- 対称原理
- 階層原理
- 線形原理
- 透明原理
- 明証原理
- 安全原理
単純原理
単純原理とは、「シンプルにこだわる」という原理。
極論、プログラミングの初心者でも読めるよう、一貫して単純なコードを書くようにする。
そのために、複雑で全体的な関連性を重視するのではなく、局所的な完全性を重視するようにする。
【意識すべきこと】
自然なコードを心がける。高級なテクニックを使わず、単純なやり方で通すようにする。むやみにコードを複雑化、肥大化せずに、単純で小さいままに保つ。
同型原理
同型原理とは、「形にこだわる」という原理。
同じことは、同じように扱うことにこだわる。
例えば、あるモジュールにおいて、そこで扱う数値の単位が統一されていたり、公開関数の引数の数が統一されていたり、使用順序が統一されていたりすること。
【意識すべきこと】
コードに一貫性を持たせる。
自分の実力をアピールするため、他の部分との一貫性など無視して、スマートで独創的なコードを書く人がいる。コードは堅牢でシンプルにしておかなければならないのに、ほとんど無意識に、複雑なものにしてしまう。自己満足には、高品質なコードほどの重要性はない。独創性を抑制し、一貫性を優先する。
対称原理
対称原理とは、「形の対称性にこだわる」という原理。
上があれば下、左があれば右、アクティブがあればパッシブというような、対称性にこたわる。
【意識すべきこと】
- 条件の対称性：制御条件に整合性を持たせるため、反条件の整合性も検討する。
- 例外の対称性：例外的な状況を考慮しつつ、それを極力排除する。特殊なケースがあまりにも多い場合、要求を見直し、コードから例外的状況を出来るだけ排除する。
- 命名の対称性：「set/get」「start/stop」「begin/end」「push/pop」
階層原理
階層原理とは、「構造が階層であることにこだわる」という原理。
物事の主従関係、前後関係、本末関係など、階層関係を常に意識し、整理された関係性を構築する。階層ごとに処理を取り決め、同じ種類の処理が異なる階層間に渡らないことが重要。リソースの獲得を行ったら、同じ階層でリソースの解放を行う。
【意識すべきこと】
コードの各々について、抽象レベルを意識して、階層構造を構築する。１つの階層は、同じ抽象レベルのものだけで構成する。
また、上位から見た時に、下位レベルは、「それを外部から見ている」ような視点で記述する。上位レベルの、下位レベルを呼び出すコードがわかりやすくなる。
線形原理、透明原理
線形原理とは、「処理の流れは直線であることにこだわる」という原理。
透明原理とは、「見通しがよいことにこだわる」という原理。
ある機能は、いくつかの機能の重ね合わせによって実現されている（線形結合的である）のが、シンプルでよい構造。
逆に、スイッチでコードを制御したり、状態の数をむやみに増やしたりすると、コードがわかりにくくなる。このようなことを避け、コードの見通しをよくする。
【意識すべきこと】
処理の分岐を少なくする。処理の流れを直線的に読めるようなコードにする。
そのためには、特殊な振る舞いを、主処理に混ぜて書かないようにすること。処理の一貫性やルートにこだわり、時にコードを俯瞰して、複雑となっていないことを確認する。
また、保守していくうちに複雑になりすぎたものに関しては、再構築することも視野に入れる。自分だけではなく、後に続く人のためにも、明確で堅牢な設計にしておくことを心がける。
明証原理
明証原理とは、「ロジックの明証性にこだわる」という原理。
明証性とは、はっきりと証明すること。つまり、一見して明らかに正しい、と言えるようなコードを書くこと。
【意識すべきこと】
ロジックは直感的でわかりやすいものにする。コードを読んでいる人が疑問に思うようなことは、排除するか、コメントしておく。
また、すぐにそれとわかる、誰でも同じことを想像できる用語を使うようにする。特に、意味のない変数名などを使わないように気を付ける。
安全原理
安全原理とは、「安全性にこだわる」という原理。
必然性のないところや曖昧なところは、安全サイドで設計・プログラミングしておくこと。
これは、ありえないという条件をあえて考慮して、コードを書くということ。
【例】
- あるif文に対して、ありえないと思いつつもelse文を考慮する
- あるcase文に対して、ありえないと思いつつもdefault句を考慮する
- ある変数に対して、ありえないと思いつつもNULLチェックを行ったりする
【意識すべきこと】
すべての動作を洗い出し、それぞれが安全になるよう考慮する。要件を理解し、機能を理解し、場合分けをコードに正しくブレイクダウンできると、ソフトウェアが安全に動作する確率が高くなる。
ただし、人によってブレが出てはいけないので、コードを書く前に、ある程度規約として定めておくようにする。
