良書を読んで学習するのが一番なのかもしれませんが、YouTubeにもかなり良質な動画があるので、特によかったと感じたものをいくつかまとめます。
設計力を上げるバリエーションの見極め術
コードの中に出現するバリエーション(変更されやすい部分)について、どう向き合うべきかが解説されています。
重要なこと
- バリエーションとなりえる箇所がどこかを想像する
- バリエーションっぽいものが現れた時に、安易に条件分岐を書かずに一旦立ち止まって今後の変化パターンを想像する
- バリエーションとは、言い換えると処理が分岐するきっかけ。if...elseif...elseif...みたいに書いてしまいそうなら、その部分はバリエーションとして捉えるべきかも
- そこで一旦立ち止まって今後どういうバリエーションが増えそうかを考えることが大切
- ただし、その想像には業務知識が伴っていなければならない。業務知識が伴わない想像は妄想
- なぜならバリエーションが発生するきっかけは、ビジネスの変化であることが多いから(消費税とか元号とかそういうものももちろんあるが...)
開発現場で役立たせるための設計原則とパターン
設計について、単一責任の原則・オープン/クローズドの原則・凝集度と結合度 を用いて、今ある問題に対してどうコードを設計していくかが具体例を交えて解説されています。
重要なこと
- 設計とは一塊りになった問題を分割して構造化すること。ただし闇雲に分割するのはよくない
- いろいろな設計方法やパターンがある中で、問題に対して最適な選択肢を選んで分割し構造化するといい
- 設計する際は、構造化する->設計原則にあてはめてレビューする...を繰り返す。一回構造をつくってそれで終わり、ではない
- 設計原則を知ることの何がいいのか -> コードの構造の良し悪しを根拠を持って判断する/言語化する助けになる
- 設計原則は大切だが、どこが変わりやすく、どこが変わりにくいのかを知らないと使えない。問題を捉え損ねたまま設計を考えるべきではない
- 問題に向き合い、それに対して適切な構造を与えることが大切
- 変わりやすい部分がわからない時は、現在わかっている範囲のみで極力シンプルにしておくべき
SOLIDの原則ってどんなふうに使うの？オープン・クローズドの原則編
SOLIDのOに焦点を当てています。既存コードからバリエーションを判定する方法や、抽出したバリエーションの軸に沿ってリファクタリングする流れなどが、先輩後輩の対話形式で解説されています。
重要なこと
- バリエーションには既知のバリエーション(考慮済み)、隠れたバリエーション(考慮されているが扱いが不完全)、未知のバリエーション(全く考慮されていない)などが存在する
- どのバリエーションが一番コードに対して影響を与えるかを考え、一番影響があるものを軸にするといい
- バリエーションの軸に沿ってコードをまとめ、拡張可能かつ修正不要の状態に持っていければ、OCPに準拠しているといえる
Becoming a better developer by using the SOLID design principles
SOLID原則の各項目について、サンプルコードを使って網羅的に解説されています。
SOLIDについて調べ始めるにあたって、まずこの動画を見るのが一番わかりやすいんじゃないかと思いました
各項目の解説は動画に任せるとして、それ以外にもっと重要なことが話されていました↓
重要なこと
- SOLIDは各原則がつながっているので、どれが欠けてもよくない
- ただし、あくまでSOLID "原則" であってルールではない
- SOLIDに準拠させようとした結果、コードが散らばってメンテや拡張がしにくいなら、それは何かが間違っているかもしれないので一度立ち止まったほうがいい。何を達成(解決)したいのかを考えるべき
- 道具であって、準拠させることがゴールではない
全体を通して言われていること
設計よりも先にまず問題(解決/達成したいこと = ゴール)についての理解を深めることが大切で、その問題に対するアプローチ方法を考える段階になって初めて設計方法が活用できる、ということがどの動画でも語られていました。
逆に、問題を正しく捉えないまま設計しようとすると、おかしなことになるということも解説されています。
思うこと
解決したい問題について正しい知識を得るには、コードを見ているだけでは足りないということを認識しました。
自分が今携わっているプロダクトはどういうふうに会社のビジネスに貢献しているのか、今実装している仕様はプロダクトが抱えるどんな問題を解決するのがゴールなのか...などビジネスサイドへの関心を持ち、ゴールは何なのかをしっかり対話することが重要なのだろうと思います。