📚

ソフトウェアエンジニアをしていて影響を受けた5冊(+α)

2022/07/24に公開

他の方の記事ですが、読んでいておもしろかったです。記事に出ている本はClean ArchitectureとTDD、LeanとDevOpsの科学くらいしか読んだことなかったです。

また自分も書くことで、他の方も記事を書くようになり、ついでに他の方の記事を読んでみるなどしたいなと思ったので書いてみます。

https://panda-program.com/posts/introduce-five-books

私はソフトウェアエンジニアとしてのキャリアはまだ7年くらい[1]なので短い方ですが、約7年間の中で読んで印象に残ったものを紹介します。

  • 計算機プログラムの構造と解釈
  • Scala関数型デザイン&プログラミング
  • Effective Java
  • Programming Rust
  • 実践ドメイン駆動設計

なお、この記事ならびに本のリストは誰かの役に立つことは想定しておらず、単に自分が読んで影響を受けているなあと感じる本をまとめています。つまり自己満足です。

加えてこの手の記事を書く際には、一応筆者のプロフィールを書いておくと、その人がどういう指向の人かつかみやすいと思うので記事の最後に載せておきました。

計算機プログラムの構造と解釈

https://www.amazon.co.jp/-/en/ハロルド-エイブルソン/dp/4798135984/

何かのブログでおすすめの一冊として紹介されていて、やってみるかと思い買ってやった本でした。結果飛ばし飛ばし取り組む形にはなりましたが、なんとか通読した記憶があります。

私はコンピューターサイエンスなどはとくに大学などでやったことがなかったので、まずそもそもコンピューターサイエンスの基礎の基礎を学ぶにはいい一冊だったと思います。いわゆるコンスセル、map や filter などの動作原理や、ストリームというデータ構造の使いこなし、並列性の理解などで大変お世話になり、今でもここでの演習は生きていると思います。

加えて、業務中に出てくる「プログラミング言語」や「データベース」なんかが、実は Lisp(本書では Scheme)で0から作れてしまうのだ、自分にもできた、というのが、なんか衝撃でした。これはつまりプログラミングでなんでも作れるということを知れたことであり、大きなブレイクスルーだったなと思います。今となっては当たり前ですが…。

Scala関数型デザイン&プログラミング―Scalazコントリビューターによる関数型徹底ガイド

https://www.amazon.co.jp/-/en/Paul-Chiusano/dp/4844337769/

転職して Scala を触るようになって読んだ本でした。私は Java エンジニアを通じて Scala エンジニアとして転職したのですが、Scala で最初苦労したのは filter や map 、flatMap などをはじめとしたいわゆる「コンビネーター」を利用したコレクションの操作でした。本書のエクササイズをこなしていくと、それらを使いこなすことができると同時に、そうしたコンビネーターの裏側にある深淵な世界を覗くことができます。

Scala の界隈だとほぼ必読書のようなポジションにある一冊で、Scala で実務をしはじめる方(新卒が特にですが)には常におすすめしていました。

私自身は、勉強会などを通じて1、2年かけつつなんとか読み切って使えるようになったかなという感触をもっています。この本を消化した後に見える景色は間違いなく変わりますが、上述した『計算機プログラムの構造と解釈』と同様、読んで理解するにはなかなか苦労する一冊でもあります。

読んでよかったなと思うのは、やはり関数型プログラミングという新しいプログラミングパラダイムへの視野が広がった点です。とくにモナドを中心とした体系立った議論は、その後の私自身のプログラミングのスタイルに大変大きな影響を与えました。Rust をはじめとするマルチパラダイムなプログラミング言語に取り組む際にも、このような関数型側の経験は大きく役に立ったように思います。

Effective Java

https://www.amazon.co.jp/-/en/Joshua-Bloch/dp/4621303252/

Java は今でも好きな言語の一つですし、近年少しずつ改善が試みられているプログラミング言語だと思います。しかし当時使っていた Java 8 は、かなり改善されて使いやすくなっていたとはいえ、Scala などの後発の言語と比べると、主に言語の機能面でのサポートの少なさからバグの埋め込みにくさや安全性の面で劣る面があったと思います。Scala を触った際には、「Effective Java」で見た注意点を踏まないようにできる機能が標準で入っててすごいなあと思ったものでした。

『Effective Java』は、「エンバグしにくく」「開発者間でコミュニケーションをとりやすい」コードになるようにするにはどうしたらよいか、という問いについてよく教えてくれた一冊だと思います。今でも時折、「Effective Java に書いてあったこの話、気をつけよう」と思いながらコーディングすることがままあるほどです。普段はモダンな Rust を書いていてさえ、そう思うことがあります。

Java を使うエンジニアであれば一読の価値があると思いますし、また Java を使わないエンジニアであっても、Java 特有のコンテキストな節を除いて読んでみても価値がある一冊かもしれません。

(当時読んだ版はこちらの第2版です)
https://www.amazon.co.jp/EFFECTIVE-JAVA-Java-Joshua-Bloch/dp/4621066056

Programming Rust

https://www.amazon.co.jp/-/en/Jim-Blandy/dp/1492052590/

私が Rust をはじめた当時は、これといって Rust に関する書籍はまだなく、しかも日本語訳は The Programming Language 第1版(Rust の公式ドキュメントのようなもの)しかないという状態でした。ただ、はじめてから2ヶ月後くらいに書籍がオライリーから出るという情報を聞き、予約注文して買った記憶があります。結果、発売が何度も延期?されて半年待たされてようやく手に入れた記憶があります。

この本を一言で表すのは難しいのですが、いつ読んでも新しい発見があるような一冊かなと思います。発見として多いのは、プログラミング言語に登場してくる概念のこれまでの歴史などが多いように思います。知らないことはまだまだ多いから、何度も読んで1つ1つマスターしていこうと思わされる1冊です。Rust の哲学についてよく説明されているのもそうですし、またたとえば浮動小数点数や文字列型、メモリに関する話などが深掘りされて丁寧に説明されている印象をもっています。

(当時は第1版でした。リンクのものは第2版です。)

実践ドメイン駆動設計

https://www.amazon.co.jp/-/en/ヴォーン・ヴァーノン/dp/479813161X/

エリックエヴァンスの『ドメイン駆動設計』じゃないのですか、とお叱りを受けそうですが、実はそうなんです。

この本は新卒の頃に買ったと思うんですが、当時「ドメイン駆動設計」という言葉を全く知らなくて、隣の席に座っていた上司の机の上にエリックエヴァンスの例の本が置いてあって、それで手元の端末で検索していろいろ調べていました。そうしたら、「Repository」「Service」のような実業務で出てくるけどよくわからないなと思っていた単語がいろいろ解説されていました。当時、金融業務で使用されるリスク管理計算機のコードが膨大で全然読めなくて、ちょっとでも読める手助けになるならと思い、本屋に出向いてドメイン駆動設計の本を探したことを思い出します。

ただ、エリックエヴァンスの方はあんまり実装が載ってないじゃないですか。なので、本屋さんでエリックエヴァンスの本の横に置いてあって、 Java でのサンプルがたくさん載っていた『実践ドメイン駆動設計』の方を先に手に取りました。

実践ドメイン駆動設計は実際に写経したり、あるいはエッセンスを取り出して自分で1からシステムを組んでみるなどして、1つ1つのコンポーネントの使い方を練習しながら身につけていきました。実際これが役に立って、結構実装力が上がったなーと感じた記憶があります。

ちなみに、数年後にちゃんと『ドメイン駆動設計』自体も手に入れて読みました。

今はもうそんなにドメイン駆動設計への熱量がないのですが、今でも私のアーキテクチャ観に大きな影響を与えていると思います。

追加で5冊をあげるなら

もし「10冊紹介してください」と言われたら。

最後に

上にはリストアップしませんでしたが、実は数年前に書籍を共著で執筆しました。普段から記事を自分で書くのは好きだったのですが、本を書いて人に買ってもらうレベルの文章はこれがはじめてでした。本にするとどうしても買ってくれる読者という存在と向き合う必要が出てくるので、情報を正しく伝える責任や義務やより大きく乗ったと思いました。

他の方の影響を受けた5冊も読んでみたいです!

筆者について

現在はアメリカの企業の日本法人でソフトウェアエンジニアをしています。主に高速性が要求されるサーバーを Rust で実装しているほか、データ基盤の改善などにも取り組んでいます。基本的にはアーキテクチャを考えたり、技術を組み合わせて問題をどう最適に解くかといった業務に関心がある&そういった業務を普段は行なっており、マネジメントやチームビルディングにはそこまで深い関心があるわけではないタイプです。

脚注
  1. 実は最初の3年は IT コンサルタントをしていて半分開発業務ではないこともしていたので、実質4年くらいがソフトウェアエンジニアとしてのキャリアの期間になります。 ↩︎

Discussion