2023年に読んでよかった技術書3選
昨年は約20冊の技術書を読んだ。
年が明けてしまって久しいが、今更ながら昨年読んでよかった技術書について書いてみたい。
Googleのソフトウェアエンジニアリング
Googleのソフトウェア開発現場において、実際に浸透している風土や規約が詳細に記載された本。
全25章、約700ページの大ボリュームだった（お腹いっぱい）
オライリーのEbookストアにてPDFで購入して読んだ。
単にコードを量産するだけの「プログラミング」ではなく、有用性のある稼働期間中は保守・拡張できるよう「ソフトウェアエンジニアリング」するためにはどうすればよいか？という問いに答えてくれる。
変更すべき全てのものを安全に変更可能で、かつコードベースの存続期間を通してそれが可能であるとき、組織のコードベースは持続可能である
「文化」「プロセス」「ツール」という切り口から、持続可能な開発活動を支える具体例が示される。
持続可能性は複数の要素の影響を受ける。
技術の詳細ではなく「文化」から入ってゆくのがこの本のおもしろいところ。技術屋はソリューションを技術に求めてしまいがちだが、ソフトウェアエンジニアリングは技術だけの問題ではないのだ。
ソフトウェアエンジニアリングとはチームによる取り組みである。
「文化」のセクションでは、HRTといったチーム開発をする上での心がけから、リーダーシップ、生産性計測に至るまで述べられている。
また名言が多く、たまに読み直すと良いリマインドになる。
自分という存在と、自分のコードとは別だ。これを何度も唱えてほしい。自分は、自分が作るものとは別だ。
「プロセス」「ツール」のセクションでは、ルール・コードレビュー・ドキュメント・テスト・バージョン管理・静的解析・依存関係管理・CI/CD などなど、これまた詳細に解説されている。一部、Googleの内部でしか使われていないようなツールの解説も含まれているが、それを除けば殆どがソフトウェア開発現場で実践可能なプラクティスであるはず。
通読が億劫な方は、課題を感じている章をつまみ読みするような辞書的な使い方をしてもよさそうだ。
A Philosophy of Software Design
ソフトウェアの複雑さと闘うにはどうすればよいのか？という本。
AmazonのKindleで購入して読んだ（日本語版が出版されておらず洋書しかない）
平易な英語で書かれていたので、2割ほどまで辞書を引きながら原文で読んでみたが、あまりにも捗らなかったため、残りの8割は機械翻訳にかけながら読み終えた。
場当たり的な「戦術的プログラミング」では良い設計に至るのはほぼ不可能であり、保守が困難となり、結果として開発速度を落としてしまう。
著者は長期的な視点での設計を行う「戦略的プログラミング」をすることを推奨している。
継続的に小さな設計への投資を繰り返すことで目先の作業工数は増えるものの、長い目で見るとスピードが出るという主張だ。
モジュール設計においては、インターフェースが広くて機能が浅いShallow Moduleよりも、インターフェースがシンプルで複雑さをうまく隠蔽したDeep Moduleを作るとよいそうだ。
The best features are the ones you get without even knowing they exist.
モジュールは利用するクライアントから見て使いやすくてなんぼであり、実装の詳細を知らなければ正しく使えないモジュールはソフトウェアの複雑さを高めてしまう。
最高の機能とは、その存在すら知らずに得られるもの。言うは易しだが、技術者としての腕が如実に問われる。エレガントな設計ができるようになりたいものだ。
他に、思想強めな主張として「コメントしっかり書け」「例外を使うな」という章もあった。
コメントを書く書かないについては賛否両論あるが、著者は「複雑さを隠蔽する」ということにフォーカスしたコメントの書き方を提案している。私も、認知負荷を軽減するためのコメントについては積極的に書いてゆくべきだと思う。
例外については、Unixのファイル削除についての例に唸らされた。
Unixでは削除したいファイルがOpenしている場合、すぐに消さずに削除マークをつけ、削除操作を正常に返すことで例外を発生させないようにしているらしい。削除マークがついたファイルは定期処理によって後ほど削除される。
例外は使わないに越したことはないが、実際にソフトウェア開発しているとUnixの例のような解決策がとれないことも多い。著者の主張に傾倒しすぎないバランス感覚は必要かもしれない。
単体テストの考え方/使い方
品質の高い単体テストを書くために知っておくべき基礎知識や実装パターンについて記載された本。
達人出版会にてPDFで購入して読んだ。
Googleのソフトウェアエンジニアリングにも各種テストの章があり十分詳しく説明されているが、この本はより緻密に解説されている。
モックの使いどころや、単体テストと統合テストとの棲み分けなど、テストそのものについての説明はさることながら、設計にも踏み込んでおり読み応えがある。
もし、クライアントが1つの目標を達成するのにテスト対象となるクラスが提供する複数のメソッドを呼び出す必要があるのであれば、そのクラスは実装の詳細を漏洩していると見たほうがよいでしょう。理想とすべきAPIの設計は、いかなる目標であれ、1つの操作で目標を達成できるようにすることです。
テストは炭鉱のカナリアであり、テストがうまく書けないということは、設計に何か悪い点が潜んでいる兆候かもしれない。
ヘキサゴナルアーキテクチャや関数型アーキテクチャにも踏み込み、副作用を分離して高速な単体テストをより厚く書くための手法も述べられている。
この本は自分の中でテスト設計の指針となったし、前職のチームでは共通理解を育みたかったため輪読会も開催した（つまり2回読んだ）
おわりに
ピックアップした3冊は全て、目指すところは「持続的開発」であったように思う。
長い目でソフトウェア開発してゆくことに対して課題を感じていた1年だったのかもしれない。
2024年も貪欲に読んで、ものづくりしていきたい。
この記事が気に入ったらサポートをしてみませんか？