「Good Code, Bad Code」を読み切った

正確には「Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考」という本を読み切りました。

総評

良い本でした。
いろいろな考え方が丁寧に解説されています。
対象読者で想定されているとおり、経験の浅いエンジニア向けです。

書籍によっては間違った内容を堂々と載せているものもありますが(最近販売停止になった本もありましたね)、本書については大丈夫です！
思想に複数の派閥があるような場合は、筆者の思想をメインに書きつつも、異なる思想についても説明されています。特定の思想を押しつけられるということがありません。

若いエンジニアの皆さんは是非本書に読み、開発についての考え方を学び取ってもらいたいです。

前提の考え方

本書は3ページ目にして素晴らしい本だと確信しました。
エンジニアであれば「Good Code, Bad Code」と言われても、「そんなの状況によるだろ」と反発しかねません。開発において、唯一の正解があるということは少ないでしょう。
まさにそのことについて冒頭の「本書について」に書かれていました。

この bad と good という言葉は、主観的でコンテキスト依存であることに注意してください。また、本書で強調しようとしているように、 bad と good の間には考慮すべきニュアンスやトレードオフがあり、これらの区別が常に明確であるとは限りません。

一方的に「良いコード」「悪いコード」と決めつけることの危険性を警告しています。
本書を読む際にも、本書以外の思想に触れるときにも、この前提となる考え方は有用です。
どんなときにも通用する Good Code はありません。 Good Code だと思っていたものが、周りの状況が変化することで Bad Code に変わることもあります。
それらを意識できるようになるだけでも、一歩前進ではないかと思います。

Bad Code と言われる可能性

本書では様々な考え方を紹介してくれています。
その中でも私が気に入ったのは、本書で Good Code として書かれた例だとしても、別の思想を持つ人から見れば、 Bad Code だと言われる可能性まで記載されている点です。
いくつか紹介したいと思います。

p105 エラー通知に対する意見の対立

この話題は、特に興味深いものです。なぜなら、ソフトウェアエンジニア(やプログラミング言語の設計者)の間で、呼び出し元が回復したい可能性のあるエラーを通知するベストプラクティスについては意見が分かれているからです。ここでの議論は、「非検査例外を使用するか、あるいは(検査例外や null 安全、オプショナル型や Result 型といった)明示的なエラーを通知するテクニックを使用するか」で対立しています。

プログラミング言語設計者のような強そうなエンジニアでも意見の相違があるのであれば、どちらが優れているとは決められるものではないでしょう。
その上で筆者の意見もきちんと書かれています。

呼び出し元が回復したいと考えるエラーに対して、「非検査例外を利用しないことが最善である」というのが、筆者の個人的な意見です。筆者の経験からすると、非検査例外がコードベースの中で十分にドキュメントに記載されていることは、ほとんどありません。つまり、エンジニアにとって、どのようなエラーのシナリオが起き、どのようにそれらを処理すべきかどうかを確実に把握するのは、ほぼ不可能ということです。

少し前までは私も例外を用いたコードを書くことも好きでしたが、最近は Result 型などを利用したコードを書くことが増えてきました。
非検査例外のような発生するかどうかわからない例外を扱うコードは少し怖いなと思います。

p186 列挙型の取り扱い

列挙型の取り扱いについては、ソフトウェアエンジニアの間で多少の意見の違いがあります。型安全を提供し、関数やシステムへの無効な入力を避けるための優れた簡単な方法だと主張する人もいます。一方で特定の列挙値を処理するロジックが至るところに広がるため、きれいな抽象化レイヤーの構築を妨げると主張する人もいます。この後者のグループのエンジニアは、ポリモーフィズムのほうが優れたアプローチであると主張することがよくあります。

列挙型を用いて処理を分岐させるのか、 interface を敷く等してポリモーフィズムによって分岐させるのか、実装方法はいつも複数あります。しかし、いつでも有用な方法というものはありません。
状況に応じて、最適な実装方法を選ぶことができる柔軟な考え方を持てると良いですね。

p221 データオブジェクト

オブジェクト指向プログラミングの伝統的な考え方の支持者は、データのみのオブジェクトを定義することは悪い習慣だと考えることがあります。

メソッドを持たないオブジェクトってどうなんだ？と思うこともありますが、やはり便利なときは便利です。

多くのエンジニアは、特定の機能に結び付けなくても、一部のデータをグループ化すると便利なシナリオがあることも認識しています。

思想が異なる人から「悪いコード」だと指摘されることがあるかもしれません。
しかし、そういう考え方もある、ということがわかっていれば、反論するなり、議論するなりすることができるでしょう。

最後に

本書は様々な考え方がきちんと文章で紹介されているところが、とても良かったと思います。
私にとっては知っている内容が多く、それを丁寧に説明されているので、若干退屈だと感じることもありましたが、経験の浅いエンジニアが多くを学べる良い本だと思います。
是非読んでもらいたい1冊です。