2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ラクスAdvent Calendar 2022

Day 16

新卒エンジニアがコードレビューから学んだ二つの学び(Strategyパターン編)

Posted at

はじめに

こちらは「ラクス Advent Calendar 2022」の16日目の記事になります。
新卒で入社し、7月に現在の部署に配属。9月中旬ごろから徐々に開発タスクに取り組み始めました。
最近ではバグ修正に加え、既存APIの改修を担当することも増えてきました。
その中で先輩エンジニアにレビューをいただき、学んだ内容を次に活かすために整理していこうと思います。

まずは簡単に状況の確認をすると、以下の流れです。

  1. あるクラスで他のクラスから値を取り処理するメソッドを書き、レビューでアドバイスを貰った
  2. 実際に修正し、理解のために手元でクラス図を作成したところ、見た事のある形になっていた
  3. 以前読んだ本を見返したところ、これが「Strategyパターン」と名前が付いていることを確認した

では詳しく見ていきましょう。

レビュー内容

レビュー内容を簡単にまとめると、以下の内容でした。
最初聞いた時は改善した形をイメージできませんでしたが、今では先輩のアドバイスを理解することができます。

先輩) 「Interfaceを使って、各クラス間の依存を減らし変更し易い構造にしていこう」

問題点

今回実装したコードの問題点は以下の通りです。(クラス図は例です)

スクリーンショット 2022-12-16 8.55.01.png

  1. Aクラスは、BとCクラスの詳細(フィールドやメソッド名)を知らなければ処理ができない状態だった
  2. BとCクラスに仕様変更があった際に、影響範囲がAクラスまで広がる可能性がある
  3. 対象となるクラスが増えれば増えるほど、Aクラス内のメソッドやswitch文処理が増えてしまう

解決策

上記問題点を解決するために、以下のアドバイスを教えて貰い、修正とクラス図の作成を行いました。

  1. Interfaceを用意して、使われ方と処理内容の結果を定義する
  2. AクラスはInterfaceのメソッドのみを知り、他のクラスもInterfaceに合わせて具体的な処理内容を実装する

こうすることでAクラスは各クラスの詳細を知る事なく処理を行えますし、もし対象となるクラスが増えてもそのクラスがInterfaceを実装していれば変更する必要がありません。
また他クラスの仕様変更があった際も、Aクラスを見る必要が無くなり容易に修正が可能になります。

そして自分でクラス図を書いたら、以下のような形になっていました。
見覚えのある形だったので、本を読み返したら「Strategyパターン」と既に名前が付いた手法でした。
(クラス図は例です)

スクリーンショット 2022-12-16 8.55.35.png

そもそもStrategyパターンとは

色々探してみて一番分かり易かったのが、以下の記事

Strategyパターンは、場面によって行いたい処理を分けたい場合に、それらの処理を外部にカプセル化することで必要な場面で必要な処理を使い分けられるようにするためのデザインパターンです。
処理を行う部分とその処理を利用する部分を分けているので、より柔軟に変更を加えることができるようになります。

引用:C#でGoFのデザインパターン~Strategyパターン編~ | cloud.config Tech Blog

今回のケースに当てはめてより表現を具体的し、以下のように理解しました。

処理結果を利用する側は変更せずに、処理内容自体(アルゴリズム)を容易に切り替えられる手法

学びの整理

今回のレビューで学んだことは、主に以下の2点です。

1. クラス間の依存関係に注目

自分の書いたコードが、どんな影響を及ぼすのかイメージ出来ていないと今回の件で感じました。
また具体例や体験が無いと影響のイメージが出来ないと思うので、本や今まで書いたコードを元に練習していこうと思いました。

個人的にはこの本(現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法:書籍案内|技術評論社)が好きなので、再度読み返そうと思います。

2.本の読み方

本では読んだことあるけど、それを設計や実装時に引き出せないと意味が無いと感じました。
なので、いつどのタイミングでその知識を引き出せばいいかの「きっかけ」を
自分の言葉で整理する必要があると思ったので、今後はこのポイントを意識していきたいです。

48. GoFデザインパターンとDI (前編) w/ twada • fukabori.fm でt_wadaさんが仰っている「コンテキストとプロブレムとソリューション」の「コンテキストとプロブレム」の整理が近いイメージです。
また目の前の問題を認識できるように、「どんな構造に反応すべきか」といった嗅覚も養う必要があると考えているので、そういう本も今後コツコツ読んでいきたいですね。

まとめ

ある人にとってはそんなの当たり前だと思われるかも知れませんが、その「当たり前のレベル」を上げていかないと余裕ができず、新しい事に挑戦できないので丁寧にコツコツ積み上げていきたいですね。(みんな最初は初心者)

さて、これで以上となります!
うちの先輩方も記事を投稿しているので、ぜひ他の記事もご覧になって引き続きラクス Advent Calendar 2022をお楽しみください!!

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?