「プリンシプルオブプログラミング」を読了して、コードレビューの見直しが出来た
先週くらいにプリンシプルオブプログラミングを読了してた。
8年くらい前からある本でいつか読もうと思ってて、今年の2月くらいに買ってて積読してた。
この本を一言でいうと、プログラミングの概念・考え方の辞書だった。
知ってる単語はあるものの、概念や法則・原則などを一冊にまとめた本だった。
この本にはプログラミング基本的な法則や概念がまとめられていた。
自分はコードレビューする上での指標なった。
この本には、プログラミングのセオリー・アーキテクチャ根底技法・要件・設計原則・UNIX思想・哲学が書かれている。
プログラミングの視点・習慣・手法・法則に触れている本だった。
コード妥当性レビュー観点
自分は7つの設計原理が響いた部分だった。
7つの設計原理は、コード構造上の7つの核心観点のことを指します。
単純原理
同型原理
対称原理
階層原理
線形原理
明証原理
安全原理
この原理は、実際にソフトウエアの現場で分析された、品質の良いコードのための「経験則」のようです。
コードレビュー時のチェック観点として使っていくとよいと自分は感じた。
なぜコードレビューをするのか？
コードレビューは、ソフトウェアの品質を担保する手法として利用されます。
プロジェクトでは、複数人が同じアプリケーションに対してコードを書いていきます。
価値観やブレない（実装の揺れ）ためもリリースする前にコードレビューは必要です。
しかし、価値観や観点がないコードレビューは、指摘が散漫になってくる。
そのために7つの設計原理を意識して、コードの価値観の認識をあわせていくが価値観やブレを少なくしていくことだと私は感じています。
単純原理
コードは「シンプルにこだわる」という原理です。
複雑な全体関連性を重視するのではなく、局所的な完全性を重視することです。
フロントエンドのコンポーネント開発では、コンポーネントの組み合わせ（結合し合う）がほとんどです。
複雑なコードは、読み手や自分が後から読み取るのに時間や仕様の確認に時間を要します。
自然なコードを書くことを心がける。
複雑なところで障害やバグが入り込むのであれば、むやみに複雑化せずに単純に小さく保つことです。
これはコンポーネントを作るのを小さく作るのとおなじことだと自分は感じました。
コードレビューでは、自然なコードであるか複雑になっていないかシンプルに保てるかどうかを見るポイントにしている。
同型原理
「形にこだわる」という原理です。
同じことは同じように取り扱うことにこだわります。
例外を設けないようにすること。特別な扱いをしないことが同型原理の基本です。
同じこと整理されてる中で、異物は違うものとして際立つ。
規則がずれるとバグの原因となりやすく、コードの違和感に気づきやすくなる。
基本は異物を認めない形で進めることが、品質の維持に繋がると感じた。
これは、コンポーネントの規則にも同様なことが言える。
コンポーネント同士で、型が変わるような形になると規則性が乱れることは感じている。
コンポーネント同士のバケツリレーでも一貫したデータ構造を維持しつつ規則正しくバケツリレーをしたいと感じた。
コードレビューでは、この異物があるかどうかを見るようにしている。
対称原理
「形の対称性にこだわる」という原理です。
上があれば下、左があれば右、true / false と同じように対称性にこだわるということ。
対称性が担保できれば、読む時に予測がつきやすいコードとなり、コードへの理解が早くなると言われている。
コード設計時に対称性を考慮すると、考慮漏れが未然に防げる。
条件があれば反条件にもこだわる。
エラー条件にとっても対称性を意識して設計したいと思った。
コードレビューでは、想定外な部分をどれくらい考慮出来ているコードかどうかをみていきたい。
階層原理
「構造が階層であることにこだわる」という原理です。
物事の主従関係・前後関係といった階層関係を常に意識し整理した関係性を維持したい。
階層が整理していることは読みやすく推測しやすいコードになる。
コンポーネント設計でどのようにディレクトリをわけるか。どのようにファイルをわけるかといった部分に近い。
読み手が構造を把握しやすい形の原理で進めていきたい。
コードレビューでは、同型原理をみつつ階層が整理されているかがポイントになってくる。
線形原理
「処理の流れは直線であることにこだわる」という原理です。
普段の生活でもいえることだが、物事が直線ではないワークフローはミスが起きやすい。
スイッチが複雑な状態はコードでも日常でも同様です。
直線にこだわることは、コードのシンプルさにも繋がる。
二個以上のロジックが入り交じるようなコードは、将来のバグに繋がると感じた。
分岐の少ないコードを心がけることが大切です。
コードレビューでは、一つの関数が直感的かどうかがポイントになってくる。
関数に返すのは必ず一つを返すようになっているか。用途をみやすく書いているかを見ている。
明証原理
「ロジックの明証性にこだわる」という原理です。
明証性とは、はっきりしているかどうか。みてすぐに正しいかどうか判断できるということです。
コードが不明瞭なブラックボックスになっていることは、そこが原因でバグが起きる可能性を秘めている。
不確実性を取り除くことを意識していきたい。
コードを何度も読んで、読み手が読みやすい状態になっているコードでなければならない。
自分自身もコードに対して言語化できるコードではなければならない。
コードレビューのポイントは、明瞭になっているかが大切かと感じている。
コメントがなくても読めるコードが望ましいと感じている。
要件次第で不明瞭な部分が出てくる場合は、要件から見直すことも視野にいれて理解しやすい形のコードになるようにレビューしていくことを大切にしたい。
誤解なく伝わるようなコードを書くことを心がけたい。
安全性原理
「安全性にこだわる」という原理です。
必然性のないところや曖昧な部分を無くすことが大切です。
ありえない条件をあえて考慮することも、コードを格上で必要です。
ありえないが null や undefined といったチェックはなくしていくことが、意図しないランタイムエラー防止に繋がる。
エラー処理を実装を漏れてしまうと、たちまち安全ではないコードになってしまう。
大事故への発展を未然に防ぐために、安全であるコードを心がけて書くことをしたい。
コードレビューのポイントは、実装されたコードの安全性かどうかです。
実装されたコードを動かしてみる。ありえない条件のデータを投げてみる。
インターフェースからではおきない値をなげて、どうなるかをチェックすることも大切です。
ありえない条件が将来のバグを未然に防ぎ、エラーがおきて動かせなくなっても戻すことができるコードを維持できるようにレビューしていくことが大切だと感じた。
まとめ
ほかにもコードに対しての原則や手法・法則が書かれています。
原則や法則を知ることは、レビューを見るポイント・自分の実装時のイロハになってくると思います。
先人の考えや思想をきちんと理解して、日々の業務使いこなせるようになっていきたいと思った書籍でした。
付箋をたくさん貼ったので自分のナレッジ見直しとして、また読みたいと思いました。
この記事が気に入ったらサポートをしてみませんか？