PRのレビューでよく参照する原則

PRをレビューしていてコメントを書くときに気を付けていることがあります。それは一般的なプログラミングの原則に照らしてレビューコメントを書くということです。

この記事では、私がレビューでよく参照する原則を紹介します。

DRY原則 (”Don’t Repeat Yourself.”)

この原則において、直訳はあまり理解の助けになりません。『達人プログラマー―システム開発の職人から名匠への道』では次のように説明されています。

すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。

DRY原則において「コードを重複させない」ということはDRY原則を守るための1つの方法ですが、DRY原則が適用できるのはそれだけではありません。例えばソースコードからドキュメントを生成するためのツールを利用している場合、その生成ドキュメントが同じリポジトリ内で管理されるとしてもDRY原則に違反しているとは言えません。このケースでは開発者がメンテナンスするのはあくまでソースコードという１つの対象です。プログラムの振る舞いを変更させた場合、あなたはプログラムと同時に手作業でドキュメントを更新する必要はなく、ツールによってドキュメントを再ビルドするだけです。これが”Don’t Repeat Yourself”ということです。

例えば、バリデーターとバリデーターが許可する型定義がバラバラに記述されている場合、DRY原則を違反しています。zodのようなライブラリーを活用することでDRY原則違反を解消することができます。

SSOT原則 ("Single Source Of Truth")

「信頼できる唯一の情報源」と訳されます。SSOT原則は"Source"という単語が指すものとして、ドキュメントやデータの扱い方を示しています。

SSOT原則を実践し、ドキュメントやデータを二重管理する苦しみから解放されます。

しかし、ドキュメントにおいては注意すべき点があります。リンクや指示語などによる参照によってSSOTを徹底しようとすると可読性を損なってしまうということです。そのためバランスが大切です。

これはドキュメントだけではなく単体テストのテストコードにおいても同じです。SSOTを意識しすぎるあまりテストコードで変数を多用すると上から下に読み下すことができなくなり可読性が悪くなりますね。

KISS原則　("Keep it Simple, Stupid")

「シンプルでつまらないものに保て」と訳されます。

KISS原則の裏の格言には「早すぎる最適化は諸悪の根源」というものがあります。
早い段階でパフォーマンス最適化のためにコードを複雑にするとメンテナンス性が悪くなり、最悪コードが変更できなくなる危険があるため避けた方がいい、という意味です。

主にプロジェクトの初期のフェーズでKISS原則に言及してレビューすることが多いです。シンプルに始めて、できればプロジェクトの最後までシンプルさを保つことで、開発チームが高いアジリティーを維持することができます。

YAGNI原則 ("You ain't gonna need it.")

「機能は実際に必要となるまでは追加しないことがよい」という意味です。読み方は"ヤグニ"です。

余分なコードを書けばそれだけバグのリスクが高くなるため、必要になるまでコードを書かずにシンプルにしておくべきということです。

YAGNI原則に違反する例として、ある関数やメソッドを「便利にしておこう」と考えて過剰なオプションを受け付けるように設計してしまうことです。他には、UIコンポーネントについて使用する予定のないバリエーションを用意してしまうといったケースもあります。

まとめ

どれも開発を継続していくために重要な原則だと思います。コードを書くときもレビューするときも、これらの視点を意識していきたいですね。