コードの再利用 - 現代プログラミング勉強会
この記事は、「現代プログラミング勉強会」と称して僕が社内向けの勉強会で話した内容を一般公開できるように再編集したものです。
現代プログラミング勉強会シリーズは全4回に分かれています。
勉強会のターゲットとしては、以下のようなエンジニアを想定しています。
- 普段の業務ではレガシーなコードしか見る機会がない若手エンジニア
- 一定のプログラミング経験があるものの、主にレガシーシステムの保守を担当しているエンジニア
たとえどんな姿をしていようとも、本番環境で稼働しているコードは価値のあるものです。 一方で、コーディングスタイルや設計思想に関して言えば、いまあるものを将来に渡って盲信しつづけるのは非常に危険です。 この勉強会は、現代のアプリケーションに要求される特性を学ぶことと、これまで培ってきたプログラミングの常識について学習棄却の機会となることを目的としています。
コードの再利用
SOLIDの原則は、いずれも変更が必要になった際にその副作用を抑え込むための工夫について説明しています。 各原則はさまざまな観点から、いかにして疎結合（≒高凝集）である状態を作り出すかについて説明しています。
一方で、かねてより口を酸っぱくして言われてきたコードの再利用やDRY1の原則に関してはほとんど述べられていません。 コードの再利用性やDRYはSOLIDの原則の後でも変わらず有用な考え方ではあるのですが、有効に機能するケースが限定的であるという指摘があります。 実再利用可能なコードを書くことやDRYを適用することは非常に難しく、どちらかというと「ここコードかぶってるな」という気持ちと「ここは共通化すべきではないな」という気持ちがバチバチとぶつかり合うことになります。
コードの再利用はいつ適用すべきか
コードを共通化・再利用する箇所では基本的に結合を生み出すため、SOLIDを守りながら再利用ができるケースというのが実はそんなに多くありません。
重複については、先の抽象化の話と共通しますが、2つのロジックが重複しているかどうかはコードの見た目で判断すべきではありません。 同一のロジックが同一のユースケースで利用される場合もしくはユースケースとは関係なく単純な演算処理を行うコードが複数回出現する場合に限り重複と判断すべきです。
ロジックの見た目は似ているが実はユースケースが違うコードはそれぞれ独立した責務1をもつ場合が多いです。 一方のユースケースだけに変更が必要になった場合2、共通化を剥がす作業が必要になります。 ただ単に制御フローや処理内容が同一であるからという理由で重複と判断すると、逆に過剰な結合の原因となってしまいます。
また、モジュールがが十分に小さい世界ではDRYを遵守した設計よりも、重複したコードの存在を許容し別々に維持管理するほうがコストが低くなることも少なくありません。 SOLIDが目指す世界はまさにモジュールを小さく分割しようという思想が中心にあるため、DRYが意義を発揮しにくくなっています。
現代のプログラミングにおいて、まず重要なのは疎結合であることです。 SOLIDの原則に従い、疎結合化が成された上でなおDRYを適用すべき箇所があればコードの共通化を行います。 コードレビューに際しても同じコードがあるからと言って単純に重複を指摘するのは危険です。 まずはそれらのコードが同一のユースケースに属しているかそうでないかを慎重に判断します。
まとめ: 重複おじさんとの向き合い方
コードの重複を排除して共通化・再利用を行う場合は事前にユースケースの精査を行ってください、というのが本記事からのメッセージです。 勉強会の他のパートが長くなってしまったので、この記事はシンプルに短く終えたいと思います。
ところで、残念なことに、現実世界にはユースケースの概念を理解せずに短期的な効率を追い求める系おじさんが少なからず存在します。 もしあなたがそういうエンジニアと同じプロジェクトにアサインされてしまったら、この記事のURLを送りつけつつやさしく諭してあげてください。 おそらく聞き入れてもらえないと思いますので、できる限り早く逃げ出すことをおすすめします。