More than 5 years have passed since last update.

読みたい・読んで良かった本

Last updated at 2019-07-20Posted at 2019-07-19

前提として、私の経験はRailsメインで開発やっていてプログラマ歴3年目です。
2年ちょっと受託開発の会社に勤め、自社サービス企業に転職しました。
なのでRubyや動的型付け言語に関する話題が多めです。

転職する前に後輩にあたる方に向けて書いたものを整理し直しました。

役割や経験、バックグラウンドによって必要な知識は異なると思うので「ふーん」ぐらいに見ておいてください。

また、すでに読んだ本とこれから読みたい本が混ざっています。
全てを読み理解した上での記事ではないことをご了承ください。

▼運用しやすいコードを書くために

●設計について

オブジェクト指向設計の成り立ちや有用性を知っておいた方がコードを書く上でも読む上でも、なぜ、どのようにオブジェクト指向設計らしいコードにする必要があるのか？を念頭におくことができるので、先に知っておくといい内容かと思います。

ドメイン駆動開発(DDD)については設計手法だけでなくプロセスも含んだ話ではありますが、あくまで設計についての話題という位置付けでここに記載しました。

●設計原則

オブジェクト指向設計実践ガイドが参考になります。
Rubyを題材にしていますが、動的型付けのオブジェクト指向言語であれば参考にしやすいです。

暗記というよりは「なんかこんな原則あったな。違反してないかな？」という確認のために軽く頭に入れておいて定着するまでなんどもコードを見直して改善するみたいな運用じゃないと定着しないと思います。

- SOLID原則

オブジェクト指向設計のガイドラインの集合体。
5つの原則の頭文字をとってSOLIDと呼ばれる。

英名	和名	概要
Single Responsibility Principle	単一責任の原則	一つのクラスが持つ責任は一つでなければならない
Open/closed principle	解放閉鎖の原則	ソフトウェアのエンティティ（クラス、モジュール、関数）は拡張に対して開き、修正に対して閉じていなければならない
Liskov substitution principle	リスコフの置換原則	サブクラスは、そのスーパークラスで代用可能でなければならない
Interface segregation principle	インターフェース分離の原則	顧客に特化した細粒度のインタフェースを作れ。顧客は自分たちが使わないインターフェースに依存することを強いられるべきではない
Dependency inversion principle	依存性逆転の原則	依存は具象から抽象に向かって行われなければならない

- デメテルの法則

3つ目のオブジェクトにメッセージを送る際、異なる型の2つ目のオブジェクトを介することを禁じる。

- DRY原則

Dot't Repeat Yourself
コードの定義は1ヶ所でのみ行い、複製ではなく参照せよ。

- YAGNI原則

You Ain't Going to Need it.

必要になるまで実装するな。
将来への予想を過度に行って先回りして実装するな。

●デザインパターン

Gang of Fourと呼ばれる4人が定義した、コードの設計によく見られるパターン集。
いわゆるGoF本。
デザインパターンは23パターンあり、パターンの適用ができる場合には設計をより柔軟なものにすることができる。

過度に適用しようとするのは危険だけどこれも原則同様知っておくと強力な武器になると思います。

●読みやすいコードを書く

Clean CodeやClean Architectureはこっちに被る気がしないでもない。
コード書く時間のほとんどは読んでる時間なので、拡張しやすさや開発の楽しさにおいて読みやすさは生命線です。

RubocopやRails Best Practicesは積極的に活用するとなお良いです。

リーダブルコード

●テストを書く

- どのようにテストを導入・運用していくのか

テストを意識していないコードに対してテスト書こうとすると、だいたいは単体テストのはずが関連するオブジェクトがあれこれ必要な状態になったり、そもそも開発プロセスの見直しが必要になったりとかで、問題として単体で完結しづらい部分です。

テストの書き方はもちろん重要ですが、設計手法を知る、導入方法について包括的に知る、あるべきプロセスについて学ぶなども並行で行う必要があります。

ちなみにテストの自動化を行なっている企業とそうでない企業との文化的な溝は大きいなと感じています。
teratailのこの投稿はテストを導入していきたいと考えている方には参考になると思います。

レガシーコード改善ガイド
テスト駆動開発
Everyday Rails - RSpecによるRailsテスト入門
- また、Everyday Railsの訳者である伊藤淳一さん(@jnchito)が書かれているRSpecの記事は非常に参考になります。Everyday Railsと併せて読んでいくとかなり体系的に学ぶことができます。

▼効率のいいコードを書くために

●SQLの効率を高める

コードが遅くなる原因のだいたいはSQL。アンチパターンを知って避けるだけでも改善はしやすくなります。

SQLアンチパターン

●コードの効率を下げる要因を知る

Rails Best Practicesがヒントになりそう。
gemで静的解析挟んでcommitに対してコメントをつけてくれるようにCIの設定を行うといいのではないかと思います。

▼効率よくコードを書くために

コーディングを支える技術
エディタやIDEの使い方について、ショートカットを学ぶとか、Qiitaの記事を見るとかも有用です。
- 必要になったらググるというやり方も身につきますが、その場合自分の想像の範囲内でしか知識が増えないので、ショートカット集なんかは手元に印刷しておいておく方がいいと思います。

▼Ruby・Railsについて学ぶ

この２冊の内容を押さえていれば仕事で困ることはないと思います。

メタプログラミングは動的型付け言語の強力な武器なのだと思いますが、それよりは設計や開発プロセスを整備する方が効率化やストレスフリーという点から優先度が高いと思います。

▼安全なWebアプリケーションを作る

体系的に学ぶ安全なWebアプリケーションの作り方第2版脆弱性が生まれる原理と対策の実践

▼Webアプリケーションの仕組みについて知る

この知識を抜きにWebアプリケーションについて理解するのはまず無理かと思います。
デバッグする際の切り分けの際にも役立つのでマストで押さえましょう。

Webを支える技術 -HTTP、URI、HTML、そしてREST

▼プログラマとしての原理原則や心構えを学ぶ

エッセイ形式で読みやすいものが多いので帰りの電車なんかでふんふん言いながら読むとモチベーションにも繋がります。
避けるべきパターンがわかればプロセスについて組み立てたり問題を事前に察知したりしやすいです。

やや毛色が違いますが、学び方について具体的な根拠を伴って教えてくれる本です。
自主的な学びが重要なエンジニアという職業において、学び方を知っているというのはあらゆる場面で能力を引き上げるチャンスになります。

エンジニアの知的生産術

▼効率のいい開発・運用体制を構築する

Docker、Kubernetes、CIツール、ChatOps、監視ツール(サーバー監視、アプリケーション監視、ログ監視)あたりを押さえておけばかなり効率化が図れるようになるんじゃないかと思います。

▼開発手法・開発体制について学ぶ

個人の能力をさらに活かすためにはプロセスやチームのあり方が重要になります。
カイゼンジャーニーが一番実践的です。
チーム開発実践入門はより開発手法としての面が強く、カイゼンジャーニーは開発体制としての面が強いです。

▼組織・プロセスについて学ぶ

開発チームの改善とかを考え始めると結局組織のあり方・プロセスのあり方そのものに行き着くなと思います。
組織のアンチパターンについても知っておいて損はありませんし、開発組織がこれまでどのような変遷を辿ってきたのかを知れば、自分たちの現在の位置を相対化できます。

改善を行うためには現在地と向かいたい先とをそれぞれ知る必要があります。

▼学び方について

目的は?(Why)
どのように?(How)
具体的には?(What)

の三つに対して疑問を持ちながら本を読み進めましょう。
本を読む前に三つの問いに対する記入欄を作って、ノートを取りながら学ぶと知識を体系化しやすくなります。

疑問に対する仮説が伴っていれば学びがさらに深まります。
仮説と検証してみた結果(自分の仮説と違った部分、仮説を補強した部分とそれに対する自分の考え)を記入していくのが効果的かと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up