はじめに
本記事は、
の参加記事です。
ちょうど一年前くらいに、
このような記事を書きました。今回は、Webエンジニアとして新卒入社してから１年間で出会った素晴らしい本の中から、特によかった技術書5冊を独断と偏見でまとめた記事になります。
エンジニア一年生で読んだ本
自分は技術書は専ら紙で読む派です。色々と不便なところもありますが、電子書籍は味気なく感じる...あと本棚に背表紙が並んでいるのをみると幸せになります。
この中から、特によかった本5冊を紹介します。
特に良かった本
レガシーコードからの脱却 -ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
構造のわかりにくい複雑に絡まり合ったコード、いわゆるレガシーコードをどう改善するか・どのように開発を進めていけば生まないようにできるかが書かれた本です。
コードを書くときに気をつけるべきチェックポイント（疎結合・凝集性の高いメソッドを書いているか？）から、ペアプログラミングといったチームで協働してプロジェクトの改善サイクルをつける方法まで、さまざまなスコープからソフトウェアを改善するやり方を紹介しています。
直接コードを書く開発者だけでなく、チーム全体の成果をドライブするプロジェクトマネージャーにもおすすめの本です。
clean Architecture -達人に学ぶソフトウェアの構造と設計
アーキテクチャのルールはどれも同じである！という前提のもと、変更に強いアーキテクチャとはどのようなものか、その基本として知るべき内容が書かれています。
ただ、具体的な実装方法というより思想について説明する内容のため、一度読んでも「結局なにがどういうことなんだ...?」「どうやって実装に落とし込んでいけばいいんだ？」とすんなりと頭に入りづらいです。
実際に設計思想を落とし込んで実装する際に読み返すことで、「なるほど、この部分はこういうことを言っていたのか」という学びが何度も得られます。本だけで完結するのではなく、実際に手を動かしながら読むことをお勧めします。
イラストでわかるDockerとKubernetes
タイトルの通り、DockerとKubernetesを豊富なイラストを交えてわかりやすく解説してくれる本です。
この本に出会うまでは、Dockerイメージのレイヤー構造やK8sの概要についてよくわかっていない状態でしたが、イラストですんなりと理解することができました。
Dockerを触っていない段階で読む本というより、Dockerコンテナでの開発・サービス提供の経験がある程度ある段階で読むことで深い学びが得られるほんかなと思います。
プログラミング言語Go
特定の言語によった内容の技術書なのですが、この本を読むことで体系的にGo言語を学ぶことができます。
ボリュームもあり、基本的なリテラルの書き方から言語仕様について踏み込んだ一冊となっているため、難易度は易しめではないですが、Goの細かい言語仕様について理解することができます。
実際にこの本を読んだことによって、解決できた問題もありました。
公式ドキュメントや、スターティングGo言語等の入門書を読んだあとにこの本を読むと良いと思います。
[増補改訂]ビッグデータを支える技術 -ラップトップ1台で学ぶデータ基盤のしくみ
データ分析の方法ではなく、「データ処理をどのようにシステム化・自動化するか」に焦点を当てて扱った内容になります。列指向ストレージによるデータ処理の高速化から、Spackなどの分散処理フレームワークの利用、データの集約・整形・学習までのワークフロー管理など、現代的なデータ分析基盤の構築について幅広い内容を学ぶことができます。
「コーディングを支える技術」に代表される、技術評論社のWEB+DB PRESS plus「〇〇を支える技術」シリーズは本当に読みやすいです。おすすめのシリーズです。
蛇足: 自分流、技術書との付き合い方
ここで記載している内容には、個人の主観的推論にのっとったものが多くあります。
この一年間技術書を読む中で、自分の中で技術書に対する付き合い方が徐々にわかってきたような気がしてきました。
蛇足として、自分の技術書に対する考え方を残しておこうと思います。
技術書の内容は、すぐに役に立つものというより、自分の考え方の幹となるもの
新しい技術に出会った！まず最初に読むべきは、技術書！ではなく、公式ドキュメント
公式ドキュメントや、Qiita、Zennをはじめとする技術プラットフォームの記事と比較すると、技術書の内容はどうしても古くなっていたり、直面している課題にすぐに適用できないようなことが多いです。
技術書は出版物という特性上、校正・推敲・校閲を何度も繰り返し、製本を経て発売されます。また、内容に関しても体系的なものが多いです。
そこを把握しておかないと、技術書に即時的な効果を期待して、
とりあえず技術書を読めばなんとかなるだろう -> 読んだ -> 読んだあとはどうしたら良いのだろう
となってしまいます。
例えば、業務ではRailsのAPIモードで開発しているのに、Action Viewでの開発についての内容が主なRails入門書を読んでも即時的な効果はあまり見込むことができません。
まずは公式ドキュメントを読み、ある程度理解した上でそれでも必要になった場合に、チュートリアル系の技術書に手を伸ばすのが良いのかな、と思います。
技術書を読むことで、基礎体力がつく
見出しにも書いたのですが、技術書の内容はすぐに役に立つものというより、自分の考え方などの幹になるものと考えています。
上で紹介した「プログラミング言語Go」などは、リテラルの書き方から言語の設計思想まで幅広く網羅しています。こういった内容を読むことで得た知識は、技術選定や設計、コードレビュー時の議論に、自分の主張を補強するのに役に立ちます。
必要に駆られるのではなく、自分の好奇心に従って読んだ方がいい
エンジニアとして入社する前〜エンジニアなりたての頃は、直近で必要になったから技術書を読むという動機で技術書を読んでいました。
そういった読み方は間違いではないのですが、「業務ですぐに役に立つものを身につけねば」「学んだ内容をアウトプットせねば」というように、技術書を読むことに対して必要以上に力が入ってしまい、疲れてしまいます。
自分の考えですが、技術書は、お酒を飲みながら「わからん」とか言いながら楽しんで読むのが一番かなと思っています。本を読む当時は直近で全く必要じゃなかった低レイヤーの知識が、ある瞬間に役に立つといったことも多くあります。
おわりに
ネット上の情報やソースコードがあるから技術書は読まなくてもいい、というような意見もあるかと思います。もちろんそのような意見も尊重すべき考え方ですし、何が正しいということもないので、人それぞれの技術書との付き合い方があると思います。
技術書の良いところは、執筆段階から綿密な構想がなされ、校正・推敲・校閲を重ねられた質の高い内容を得ることができる点だと思っています。普段あまり読まない方でも、一冊興味のある本を読んでみてはいかがでしょうか。
技術書はいいぞ！