2018卒エンジニアによるエンジニア研修レポート(2)【オブジェクト指向設計・自動テスト研修】

みんなのウェディング2018卒エンジニアの徳元です。前回(2018卒エンジニアによるエンジニア研修レポート(1)【フロントエンド研修】) に引き続き、私が受けたエンジニア研修についてまとめていきたいと思います。

今回は弊社のインフラ領域統括プロデューサーである高橋一生さんが講師を務めたオブジェクト指向設計・自動テストの研修です。

オブジェクト指向設計・自動テスト研修の概要

本研修はまずオブジェクト指向設計の基本的な考え方について触れ、Rubyによるオブジェクト指向設計と自動テストについて『プロを目指す人のためのRuby入門』を写経しながら理解を深めます。

次にRSpecによる自動テストを学び、最後にRailsのオブジェクト指向設計と自動テストについて説明を受けました。

なぜオブジェクト指向で設計をするのか

オブジェクト指向で設計をする大きな理由として、一生さんから「変更コストを最小限にするため」、「まずい設計に対抗するため」という二つを教わりました。

本当の意味でオブジェクト指向設計を理解するのはとても難しいと言われているのですが、変更コストに関してここで説明されていることの一例を挙げると、ただ闇雲にコードを書いていくよりも、

  • クラスを分けて書くことによってどこに何が書いてあるのかがわかる状態になる
  • オブジェクト単位で利用することで修正が必要になった時にそのオブジェクトの振る舞いを変えることで一度に修正できるようになる
  • 責務をちゃんと分けているため変更の副作用がどこに起きるのかがわかる

といったメリットがオブジェクト指向設計にはあるのではないかと思いました。

オブジェクト指向設計のポイント

それではどのような点を意識しながらオブジェクト指向で設計をすることが出来るのか?一生さんは、以下のように説明していました。

また、それとは別の重要な観点が二つあります。

  1. クラスの凝集度(そのクラスに書くべき要素が集まっている度合い)を上げる
  2. クラス同士の結合度(依存関係の度合い)を下げる

これらのポイントは教えてもらった時にはピンとこなかったものもありましたが、実際にオブジェクト指向設計を意識してコードを書くうちにだんだんとその意味がわかるようになりました。

デザインパターン

このオブジェクト指向設計のイディオムとして、デザインパターンというものがあります。色々あるデザインパターンのうち代表的なもの4つをこの講義では教えてもらいました。 実際にそれぞれのパターンのコードを例示してもらい、なぜこのパターンを使うのか、どのようにして使うのかを具体的に教えてもらいました。

RSpecによる自動テスト

なぜテストを書くのか、なぜRSpecなのか

次に、RSpecによる自動テストについて学びました。ここで興味深かったのはなぜテストコードを書くのか、なぜRSpecなのかというところから説明してくれたところです。

一生さんによると、テストコードを書く意味は「ソフトウェアがキチンと動作してリリースできることをチームが確信を持つため」だそうです。 「ソフトウェアがキチンと動作することを確認するため」というのは多くの方がご存知のことだと思いますが、その主語が「チーム」というのは興味深かったです。

上のスライドにある「UIテストだけがあればよい」や「ユニットテストだけがあればよい」という点が間違っている理由は、それぞれのテストだけではテストしきれないことがあるからです。

RSpecを使う理由、そしてメリットとデメリットもいくつか教えてもらいました。

私はMinitest(Test::Unit)も使ったことがありますが、Minitestよりも英文っぽく書ける点がRSpecのいい点だと思います。 ただ、その他のメリットやデメリットに関しては具体的にMinitestと比較したことがないのでまだ実感しきれていないというのが正直なところです。

実際にRSpecを書いてみる

概要を教えてもらった後は、実際にRSpecを書いてみました。まずは@jnchitoさんのQiitaの記事「使えるRSpec入門」シリーズを皆で読んでいきました。 ここでRSpecに関する基本的な知識を入れた後は『プロを目指す人のためのRuby入門』を読みながらRubyの基本的な知識を改めて確認しつつ、本書のテストコードをRSpecに置き換えていきました。

『プロを目指す人のためのRuby入門』を読んでいく中で「そもそもここってどうなっているんだっけ」というような質問が多く飛び交いました。その質問のおかげで、いつもは自分が意識しない関連知識を教えてもらうことがありました。例えばクラスの継承という一つのテーマでも、以下のように関連知識を学ぶことが出来ました。

  • ちゃんとした継承をしているかどうかをチェックするのは「サブクラスはスーパークラスの一種である(サブクラス is a スーパークラス)」と読んでみてしっくりくるかどうか
  • 最近は継承よりも移譲というものを使うことが多い
    • 継承(inherited)は親クラスのすべてのものを受け入れてしまうので、危険
    • deligateであれば受け入れるものを一部に制限することができる
    • と言ってもRailsは継承がすごくて、is-a(イズア)の関係にはなっていない。そういったバコバコ継承されたなんでも出来るものをゴッドクラスという

Railsでのオブジェクト指向設計

次に、RubyではなくRailsのオブジェクト指向設計、MVCモデルやその責務の切り分け方について学びました。

MVCモデルというのはGUIアプリケーションの責務を以下の3種類に凝集したものです。

  • Model
  • View
  • Controller

この3つがどんな役割を負うのかを、一生さんはわかりやすく説明してくれました。

演習課題を通して知識を定着させる

この講義の最後には、演習課題である簡易ブログアプリの作成を通して今回学んだ知識を定着させました。

課題の内容からわかる通り、先に述べたモデルのデザインパターンを活用することが求められるような内容になっていました。

本研修を受ける上で心がけたこと

この回において私が特に心がけたことは、前回(2018卒エンジニアによるエンジニア研修レポート(1)【フロントエンド研修】)のブログの「私が学びを最大化するために心がけたこと」でまとめたポイントのうちの「詳細なメモを取りながら研修を受ける」です。

この研修ではフロントエンド研修よりも広い範囲の情報がより多く入ってきました。抽象度もそれぞれ違います。その上多くの質疑応答も加わるので、一つひとつを理解するように努めながらもとにかくメモを取ることを心がけました。

良かったところと改善して欲しいと思ったところ

この研修で特に良かったところは、Railsのオブジェクト指向設計やModelのデザインパターンについて学べたことでした。RSpecの説明の中ではモックを使ったテストに関する内容が印象的でした。

ただ、まだこの段階では私はこれらの知識を自分のものに出来ていませんでした。というのも、私はRuby Kaigi 2018のために先に述べた演習課題が始まった頃には仙台に行ってしまったからです。そのため私は、次の研修内容であるパイロットプロジェクトを通して初めてこの研修で学んだ知識の価値を実感しました。

改善して欲しいと思ったところは、一生さんによるライブコーディングの速度です。

本研修の中で、一生さんがライブコーディングをして実装の流れやテストのリファクタリングの流れをバッと見せる時がありました。しかし、私にはそれがあまりにも早すぎて理解するのが大変でした。結局ライブコーディングの中の一部分しか理解できず、とにかく「もっと知識と技術力を上げないといけない」という危機感だけが募りました。

もしライブコーディングが私たちに実装やリファクタリングの際の着眼点を教えたり、実例を通して理解を深めることが目的だったのであれば、もう少しゆっくりやってもらうとより効果的だったのではないか、と思っています。

(もしかしたらこのスピードについていけないことへの危機感を持ってもらうこともの一生さんの狙いだったりするのかもしれません・・・。)

プロとしてのオブジェクト指向設計、自動テスト

前回のブログの最後に、「仕事としてのエンジニアリングは趣味としてのエンジニアリングとは違うとわかった」という話をしましたが、今回の研修で学んだ内容についても同じことが言えます。

先に述べたとおり、テストはそもそも仕事で多くの人と共同開発をする上でチームが「これで問題ない」と確信を持つためのものですし、ビジネスとして効率的に開発を進めていく上で正しい設計に則って開発を進める事が大切だからこそオブジェクト指向設計という考え方があり、それに私たちは乗っかって開発をしているわけです。

趣味で自分の好きなアプリケーションを作るだけなら、もしかしたら「動けばいい」というものでいいかもしれません。何らかのエラーで使えなくなってもその都度直すという形で問題ないのであればテストも書く必要もないかもしれません。

しかし仕事としてエンジニアリングをする以上、サービスをより良くするためにプロ意識を持ってプログラミングをしていくことは必須です。その意味でこの研修で学んだことはプロとしてコードを書いていくための必須の基礎知識だったのだと思います。