こんにちは、エンジニアの @hanhan1978です。
弊社では、ソフトウェアの開発プロセスにおいて、ほぼ全てのプログラム修正・追加に対してソースコードレビューを実施します。本番環境にはレビューを通った変更のみが反映されます。
仕組み的な話をすると、恐らく多数の会社や団体にて行われているのと同様にGitHubのPullRequestに対してソースコードレビューを行って、Approve されないとPullRequestがマージ出来ないという形を取っています。
しかし、ソースコードレビューが常態化してくると、簡単に指摘できるような内容は少なくなってきて、「これ、あんまり良くないと思うんだけど、相手にどうやって伝えていいか分からない。」とか、「自分なら違う書き方をするし、そのほうが良いと思うけど、説得できるほど自分の頭の中で言語化できてない。」という状況によく出会うようになります。
このような状況下では、分かりやすく納得感のある指摘を出来ないので指摘しないという消極的な選択を取ることにもなりかねません。
[Philosophy of Software Design]は、私個人にとってはそのような「言語化出来てないけど、このほうが良いと思う」というプログラムの書き方を上手に言語化してくれる本でした。弊社esaには、同書籍の要約を日本語に翻訳したエントリを作ってあるため、ソースコードレビュー時にコメントと共に該当エントリのリンクを貼ることで、以前よりも明確に自分の伝えたいことを相手に表現できるようになりました。
Yaknyam Press
売り上げランキング: 19,036
手前味噌ですが、下記の目次は私が日本語に訳したものです。
目次の日本語訳
- 1章 はじめに
- 2章 複雑性の本質
- 3章 動くだけのコードは不十分
- 4章 モジュールは深くあるべき
- 5章 情報の隠蔽（と漏洩）
- 6章 一般用途向けモジュールはより深く
- 7章 異なるレイヤー、異なる抽象化
- 8章 複雑性を下に閉じ込める
- 9章 密結合が良い、または疎結合が良い
- 10章 存在意義から例外を定義する
- 11章 ２回デザインする
- 12章 なぜコメントを書かなきゃいけないのか？4つの言い訳
- 13章 コメントはソースコードからは不明瞭な事柄を記述するべき
- 14章 名前を選ぶ
- 15章 コメントを最初に書く
- 16章 既存コードの改修
- 17章 一貫性
- 18章 ソースコードは明白であるべし
- 19章 ソフトウェアの流行
- 20章 処理速度のデザイン
特に好きな章と概要
2章 複雑性の本質
同書全体においてキーワードとなる複雑性という単語に焦点を当てて、その発生理由や分類をしています。ソースコードの設計や良し悪しを判断する統一基準として複雑性という尺度を持ってくるのが、よく考えているなと思いました。
10章 存在意義から例外を定義する
私もよくやりがちなのですが、思考停止してExceptionを放り投げるような行為が何故良くないのか。そして、例外というものをソフトウェアのデザインとしてどう扱うべきなのか？章タイトル通りに、そもそも例外である必要があるのか？を含めて分析してあり、対処法も書かれています。
13章 コメントはソースコードからは不明瞭な事柄を記述するべき
弊社にもレガシーと呼ばれるソフトウェア資産があるため、本章で書かれている内容は特に大事にしなければと再確認させてくれた章です。以前からコメントはもちろん書き足していく姿勢はあったのですが、何を？どれくらい？書くということに対して徹底が足りていなかったなと思いました。
まとめ
というわけで、ソースコードレビューで何て指摘したらいいんだろう？？とお困りの方がいらっしゃいましたら、ぜひ[Philosophy of Software Design]を読まれることをおすすめします。レビューがはかどりますし、メンバー間での認識共有にも大変役立ちます。
そもそも、筆者の方も同書の利用方法としてソースコードレビューに使うのが一番良いと書かれていますので、大変おすすめです。
※英語が苦手な方は、弊社に入社すると日本語の要約が読めますね！！
