変更しやすいソフトウェアは失敗から学ぼう
情報
著者：仙場大也
発行：2022年5月12日
目次
- 悪しき構造の弊害を知覚する
- 設計の初歩
- クラスの設計
- 不変の活用
- 低凝集
- 条件分岐
- コレクション
- 密結合
- 設計の健全性をそこなうさまざまな悪魔たち
- 名前設計
- コメント
- メソッド（関数）
- モデリング
- リファクタリング
- 設計の意義と設計への向き合い方
- 設計を妨げる開発プロセスとの戦い
- 設計技術の理解の深め方
書評などなど
ソフトウェア開発は、『どのように実装するか詰める設計』『設計された通りに実装するコーディング』『設計通りに実装できたか確認するテスト』の3つで構成される。もう少し詳しく見ていくと、要件を固める上流工程があったり、『設計』と言っても基本/詳細があったりと単純に説明できるものではないが、ざっくりとは3工程という理解で良いだろう。
そんな中、本著が生かせる工程というのは実にハッキリしている。『設計された通りに実装するコーディング』だ。
ソフトウエア開発には長い歴史があり、それは失敗の歴史とも言い換えることができる。複数人が同時に編集するファイルのバージョン管理に困ったから、gitやsvnが生まれたように、過去の失敗から学んで効率化が図られてきた。それらの恩恵をエンジニアは多大に受けている。
そんな学ぶべき失敗に関して。特にコーディングに関する失敗の事例というものを、本著はまとめてある。とはいえ、ただ失敗事例をまとめただけの書籍であれば、あまり意味はない。みなさんにオススメするために本記事に書くようなこともないだろう。
本著には良いコードと悪いコードの両方が提示されている。つまり本著を見ていくことで、多くの開発に関わることでしか得られない『コードの善し悪しを判断する目』が養われていくのだ。
『設計された通りに実装するコーディング』というのは、実装できて終わりではない。実装したコードに問題がないか、有識者によるレビューが行われる。このレビューをする有識者には、『コードの善し悪しを判断する目』が求められるし、こういった力を持った人材というのはとても貴重である。
悪いコードというのは、プロジェクト全体に悪い影響をもたらす。そのことについて、第一章『悪しき構造の弊害を知覚する』において記載されている。特に設計をないがしろにしたことにより生じる弊害について、例として下記3点がまとめられている。
- コードを読み解くのに時間がかかる
- バグを埋め込みやすくなる
- 悪しき構造がさらに悪しき構造を生む
実際にコードを実行した際、何かしらの不具合が見つかったとする。その原因箇所の特定には、コードを読み解いていくことになるのだが、悪いコードはその作業に時間がかかる。これはよろしくない。
そもそも悪いコードというのは、バグが起こりやすい。ただでさえ読みにくいコードにバグが多大に含まれているとなると、プロジェクトの炎上に繋がっていく。悪しき構造のコードに対し、機能の追加や改修等を加えることで、悪しき構造に悪しき構造が付随されていく。この悪循環から脱するのは非常に難しい。
逆説的に、良いコードというのは下記の通りだ。
- 読み解きやすいコード
- バグを埋め込みにくいコード
- 後からの改修がしやすいコード
そのような良いコードを目指すために、悪いコードと良いコードの事例を見ていくことで学んでいくことができる。最初に述べた通り、これが『コードの善し悪しを判断する目』を養うことに繋がっていく。
悪いコードというのは実際に仕事で目にすれば一目瞭然だ。何をしているか分からないし、複雑に絡み合った構造は、それ以上の改修を強く拒んでいる。では具体的にどこが悪く、どうすれば良くなるかまで分からなければ、コードを読めたとはいえない。
そんな具体的な視点はどうすれば身につくのかと問われれば、いっぱいコードを見るしかないように思う。しかし、悪いコードばかり見ていてもそれがスタンダードとなってしまう。良いコードというものも同時に見なければ、善し悪しの判断はつかないのだ。
さて、良いコードと悪いコードを見る必要があることは理解していただけたのではないだろうか。
個人的に面白いと思ったのは、実装あるあるが至るところに散りばめられていることだ。例えば、第十一章『コメント』にてまとめられている内容だろうか。ここで筆者のコメントを引用しよう。
コメントは劣化コピーに過ぎないことを理解すること
コメントは実装者の思い、思想の全てが反映されている訳ではない。簡略化されたり。メンテナンス不足により過去のものとなる。そんなコメントの状態では、後からコードを読んだ人に誤解を与えてしまう。コメントは定期的なメンテナンスは勿論のこと、適切なコメントというものが必要になってくる。
悪いコード事例を提示しつつ、理屈も説明しつつ、コメントを書く上でのルールとしては下記の4つが提示されている。
- ロジック変更時、同時に必ずコメントも変更すること
- ロジックの内容をなぞるだけのコメントをしないこと
- 可読性の悪いロジックを補足説明するようなコメントをしないこと。代わりにロジックの可読性を高めること
- ロジックの意図や仕様変更時の注意点をコメントすること
それぞれの理屈や紹介されている事例については本著を読んで確認して欲しい。実装の導入教材としては適した書籍だと思う。
