前提として、私の経験はRailsメインで開発やっていてプログラマ歴3年目です。
2年ちょっと受託開発の会社に勤め、自社サービス企業に転職しました。
なのでRubyや動的型付け言語に関する話題が多めです。
転職する前に後輩にあたる方に向けて書いたものを整理し直しました。
役割や経験、バックグラウンドによって必要な知識は異なると思うので「ふーん」ぐらいに見ておいてください。
また、すでに読んだ本とこれから読みたい本が混ざっています。
全てを読み理解した上での記事ではないことをご了承ください。
▼運用しやすいコードを書くために
●設計について
オブジェクト指向設計の成り立ちや有用性を知っておいた方がコードを書く上でも読む上でも、なぜ、どのようにオブジェクト指向設計らしいコードにする必要があるのか？を念頭におくことができるので、先に知っておくといい内容かと思います。
ドメイン駆動開発(DDD)については設計手法だけでなくプロセスも含んだ話ではありますが、あくまで設計についての話題という位置付けでここに記載しました。
- オブジェクト指向でなぜ作るのか
- Clean Code アジャイルソフトウェア達人の技
- Clean Architecture 達人に学ぶソフトウェアの構造と設計
- エリック・エヴァンスのドメイン駆動設計
- 実践ドメイン駆動設計
●設計原則
オブジェクト指向設計実践ガイドが参考になります。
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。アンチパターンを知って避けるだけでも改善はしやすくなります。
●コードの効率を下げる要因を知る
Rails Best Practicesがヒントになりそう。
gemで静的解析挟んでcommitに対してコメントをつけてくれるようにCIの設定を行うといいのではないかと思います。
▼効率よくコードを書くために
- コーディングを支える技術
- エディタやIDEの使い方について、ショートカットを学ぶとか、Qiitaの記事を見るとかも有用です。
- 必要になったらググるというやり方も身につきますが、その場合自分の想像の範囲内でしか知識が増えないので、ショートカット集なんかは手元に印刷しておいておく方がいいと思います。
▼Ruby・Railsについて学ぶ
この２冊の内容を押さえていれば仕事で困ることはないと思います。
メタプログラミングは動的型付け言語の強力な武器なのだと思いますが、それよりは設計や開発プロセスを整備する方が効率化やストレスフリーという点から優先度が高いと思います。
▼安全なWebアプリケーションを作る
▼Webアプリケーションの仕組みについて知る
この知識を抜きにWebアプリケーションについて理解するのはまず無理かと思います。
デバッグする際の切り分けの際にも役立つのでマストで押さえましょう。
▼プログラマとしての原理原則や心構えを学ぶ
エッセイ形式で読みやすいものが多いので帰りの電車なんかでふんふん言いながら読むとモチベーションにも繋がります。
避けるべきパターンがわかればプロセスについて組み立てたり問題を事前に察知したりしやすいです。
やや毛色が違いますが、学び方について具体的な根拠を伴って教えてくれる本です。
自主的な学びが重要なエンジニアという職業において、学び方を知っているというのはあらゆる場面で能力を引き上げるチャンスになります。
▼効率のいい開発・運用体制を構築する
Docker、Kubernetes、CIツール、ChatOps、監視ツール(サーバー監視、アプリケーション監視、ログ監視)あたりを押さえておけばかなり効率化が図れるようになるんじゃないかと思います。
- Docker/Kubernetes 実践コンテナ開発入門
- SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 入門 監視 ―モダンなモニタリングのためのデザインパターン
- Effective DevOps ―4本柱による持続可能な組織文化の育て方
▼開発手法・開発体制について学ぶ
個人の能力をさらに活かすためにはプロセスやチームのあり方が重要になります。
カイゼンジャーニーが一番実践的です。
チーム開発実践入門はより開発手法としての面が強く、カイゼンジャーニーは開発体制としての面が強いです。
- カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド
- スクラム 仕事が４倍速くなる“世界標準”のチーム戦術
- SCRUM BOOT CAMP THE BOOK
- アジャイルサムライ達人開発者への道
- Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
▼組織・プロセスについて学ぶ
開発チームの改善とかを考え始めると結局組織のあり方・プロセスのあり方そのものに行き着くなと思います。
組織のアンチパターンについても知っておいて損はありませんし、開発組織がこれまでどのような変遷を辿ってきたのかを知れば、自分たちの現在の位置を相対化できます。
改善を行うためには現在地と向かいたい先とをそれぞれ知る必要があります。
- エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- How Google Works
- ワーク・ルールズ! ―君の生き方とリーダーシップを変える
- NETFLIXの最強人事戦略 自由と責任の文化を築く
- Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 「納品」をなくせばうまくいく
▼学び方について
- 目的は?(Why)
- どのように?(How)
- 具体的には?(What)
の三つに対して疑問を持ちながら本を読み進めましょう。
本を読む前に三つの問いに対する記入欄を作って、ノートを取りながら学ぶと知識を体系化しやすくなります。
疑問に対する仮説が伴っていれば学びがさらに深まります。
仮説と検証してみた結果(自分の仮説と違った部分、仮説を補強した部分とそれに対する自分の考え)を記入していくのが効果的かと思います。