07-共有は慎重に

「プログラマが知るべき97のこと」の７つ目のエピソードは、再利用性に関する話です。本文にも書かれていますが、基本的には再利用は正しいことであり、ソフトウェアをコンパクトに保守・拡張しやすくするもので、強く推奨されるものでしょう。しかし、コンテキストを間違えるとかえって保守性が悪くなる事もあると警鐘を鳴らしています。
コンテキストという言葉はソフトウェア開発の中で重要なキーワードです。「文脈」とか「前後関係」と言った日本語に直訳されますが、うまい訳語ともいえないのでカタカナでコンテキストと呼ばれる場合がほとんどです。ServletContextといったようにソフトウェアのクラスの中にもContextというキーワードは出現します。コンテキスト不在の議論や設計はしばしば発生します。お互いに暗黙知を前提に話を進めたり相手のスキルがコンテキストを理解するまでに至っておらず本論を議論できていないことも多いです。
これはプログラムの再利用についても同様です。そのコードの断片がどのようなコンテキストで利用されているかを解らないままで抽出をしてしまうと、物理的なリファクタリング*1とはなりますが、論理的には共通化すべきでない箇所を共通化している事になるわけです。
また、共通化に関しては別のパターンも存在します。大規模プロジェクトでSIerが取るパターンですが、「共通部品チーム」というのを作り共通化をするケースです。この共通部品チームの作る共通部品*2はほとんど使われることがありません。理由は明確で、コンテキストが不在のままで提供される上に、ほとんどが実装と並行にリリースされるからです。勿論、プロジェクトマネージャは「共通部品化によりプロダクトの品質が向上し、効率も上がっている（ｷﾘｯ」となっているのですが・・・。
シングルトンパターンを初めとしたデザインパターンも含め、プログラマは新しい技を覚えるとついつい試したくなります。また、使いにくい技をどうにかして使いこなす事が格好いいと錯覚することも多いでしょう*3。しかし、本当に必要かと自問し我慢することができてこそ１人前のプログラマなのでしょう。
「共有は慎重に。事前のコンテキスト確認を忘れずに」肝に銘じておきます。

プログラマが知るべき97のこと

*1:物理的なリファクタリングと論理的なリファクタリングは造語です。リファクタリングするときに純粋にコード断片の共通部分を見ていくのが物理的なリファクタリング、コードの論理的な意味からコードをまとめられないか？とアプローチするのが論理的なリファクタリングと定義し、両方から攻めるべきと考えています。

*2:余談ですが、部品ってキーワードは炎上プロジェクトの可能性が高いですねｗ

*3:格ゲーとかでよくありましたね