【結論】
・７つの設計原理とは、障害に強いソフトウェアが備えているコードの構造
・「単純原理」「同型原理」「対照原理」「階層原理」「透明原理」「明証原理」「安全原理」の７つで構成されている
・コードレビューにおいて、メンバーや状況によってチェックが散漫になるのを防ぐための、共通のチェック観点として利用できる
【目次】
【本題】
コードレビューに一貫性が無い問題
ソフトウェアの品質を担保する手法として、第３者によるコードレビューは非常に有用です。
しかし、レビューする人が個々の基準でチェックを行うのでは、人によってチェックの観点にズレが生じます。
また、ただ漠然とコードを読み進めて動作検証するだけでは、表面的な指摘しか出来ず、潜在的なコードの問題点を把握することが出来ません。
これらの問題を解決するには、コードレビューの観点を統一する必要があります。
そこで利用できるのが、「7つの設計原理」です。
7つの設計原理について
7つの設計原理とは、コードの構造的な問題で障害を生み出さない様にする為に、考慮すべきポイントを７つにまとめたものです。
実際の開発現場で発生した障害の根本原因を分析して、そこから導き出された根拠のある原則です。
チーム内でコードレビューを行う際の観点として共通認識を形成しておくことで、一貫性のあるレビューを行うことが出来ます。
また、コードレビューに限らず、実際にコードを書く際に注意すべき観点として用いることも可能です。
では、それぞれの原理について解説します。
単純原理
「シンプルさを徹底して維持する」という考え方です。
障害が発生するコードに共通して見られる特徴の一つに「複雑さ」が挙げられます。
もし複雑で障害を招きそうなコードがあれば、障害の入り込む余地が無くなるまでシンプルにします。
シンプルなコードは、素人っぽいので、ある程度経験を積むと、自身の知っている高度なテクニックを試したくなりますが、それはグッと堪える必要があります。
同型原理
「同じものは、同じように扱う（一貫性を保つ）」という考え方です。
例えば、同一モジュール内で使用される数値の単位が統一されていたり、関数の引数の使用順序が統一されているなどです。
同じものが同じに見えるようになっていれば、違うものが際立ちます。
これにより正常で無い部分を発見しやすくなり、バグを未然に防ぐことが出来ます。
対照原理
「対称性を明確にする」という考え方です。
例えば、命名をする際、「begin/end」という様に対称性のある名前を選ぶことなどが挙げられます。
対称性があれば、一つの事象から反対の事象も読み取れるので、予測がつきやすく可読性が高まります。
なお、例外的な状況が発生すると、それにより対称性が崩れるので、出来るだけ例外的な事象が発生しないようにする必要があります。
階層原理
「構造を階層で表す」という考え方です。
コードが階層化されていると、同一階層は抽象度が同じということが視覚的に分かるので、コードの理解を促進します。
逆に同じ階層に、違う抽象度のコードが入ると混乱を招くので、構造を見直す必要があります。
また、階層毎に処理を取り決めることで、他の階層に影響が波及しない様に工夫も可能です。
透明原理
「処理の流れを直線的にする」という考え方です。
複雑な条件文/繰り返し文や、処理の流れがジャンプする部分で、障害が発生する傾向が強いです。
処理の分岐を抑え、階層の上位から下位に向かって一直線で流れて行く処理の流れを意識する必要があります。
そうすることで、可読性が高まり、保守や追加開発もしやすくなります。
明証原理
「一見して正しいと分かる状態にする」という考え方です。
これはコードの構造に限らず、コメントを書いたり、ドキュメントを書くなどでも対応出来ます。
しかし、基本はロジックが明瞭なコードを書く様にすることが重要です。
安全原理
「あらゆるトラブルを想定する」という考え方です。
例えば、IF文で通常はありえないelse文を考慮するなどが挙げられます。
どの様な状況においても、安全に稼働し続ける様に設計を行います。
その為には、ありえない条件も含めて、全ての動作を洗い出し、それを踏まえた実装を行います。
参考情報
書籍「プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則」
《今日の学習進捗（3年以内に10000時間に向けて）》
どうも体調が悪い・・・
やはり体が資本なので、体調管理には今まで以上に気を配りたい・・・
学習開始からの期間 ：239日
今日までの合計時間：2288h
一日あたりの平均学習時間：9.6h
今日までに到達すべき目標時間：2183h
目標との解離：105h
「10,000時間」まで、
残り・・・「7712時間！」