# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
7．共有は慎重に ウディ・ダーハン(Udi Dahan)
それは私が社会に出て最初に関わったプロジェクトでのことでした．
まだ大学を出たてで，自分の能力を証明したくてしょうがなかった頃です．
毎晩夜遅くまで会社に残り，
既存のコードを読んで色々なことを学んでいました．
そして私は初めて仕事を任された時，
担当部分の作業にこれまで自分が学んできたことを
どうしても実践してみたくなったのです．
それは，コメントを入れること，
ログを取ること，
そして，内容が似通っているコードをできるだけライブラリ化することでした．
しかし，意気揚々と挑んだコードレビューで私は思い知らされることになります．
コードの再利用を安易に促進すると，
かえって顰蹙を買ってしまうのだ，ということを．
どうしてそういうことになってしまったのでしょうか．
大学では，「再利用」を優れたソフトウェア開発プロジェクトの
象徴として教わって来ました．
どんな論文や教科書を読んでも，そう書いてあったし，
経験豊かなプロのソフトウェア技術者もそう語っていたのに，
それらは全部間違いだった，ということでしょうか．
考えた結果，わかったことは，
私が1つ重大なことを見逃していた，
ということです．
それは
「コンテキスト」(脈略，前後関係)
です．
たとえ，システム内に同様の処理を行う部分が2つあったとしても，
両者のシステムにおける役割が大きく異なっていれば，
再利用によるメリットは小さいのです．
私がコードをライブラリ化するまで，
そのコードを利用する部分間に依存関係はまったくありませんでした．
元々の成り立ちが全然違うコードだったのです．
従って，状況やニーズが変われば，
各部分のロジックには
まったく別の変更が必要になる可能性が高いということです．
たとえ，コードが4行ほどのもので，
行なっていることが同じだったとしても，
それはたまたま一時的にそうなっていただけのことです．
私が入ってくるより前は，
むしろ機能は一致していなかったのです．
私がコードをライブラリ化してしまったことで，
それを利用する部分には依存関係が生まれてしまいました．
まるで，一本の靴紐を，両足の靴に通したような状態になったのです．
ライブラリのコードを一行変更しただけで，
その影響は複数ヶ所に及びます．
互いに独立していた時なら，
該当部分の保守コストは無視出来るほど小さかったのに
ライブラリ化してから，変更の度に大変な手間をかけて，
テストをする必要が生じました．
私は，システムを構成するコードの絶対的な行数は減らしたのですが，
依存し合う部分を増やしてしまったのです．
依存関係が生じる場合には，そのコンテキストが重要になります．
依存関係が生じても，
狭い範囲でのことならば，
さほど問題は生じず，
共有のメリットの方が大きくなったでしょう．
しかし，広範囲での依存関係が生じると，
システムの様々な部分がそれに巻き込まれることになり，
ライブラリのコード自体は良くできていても，
デメリットの方が大きくなります．
こういうミスはとても厄介です．
「再利用」は一般的に良いこととされており，
確かに基本的には良いことだからです．
コンテキストさえ適切なら，間違いなく有効です．
しかし，コンテキストが不適切だと，
メリットよりもコストの方が大きくなるのです．
私は今では，
システム全体の構造がわからないうちは，
コードの共有を安易に進めたりはしません．
まずは部分同士の関係をよく見て，
どこをライブラリ化すべきかを慎重に考えます．
「共有は慎重に．
事前のコンテキスト確認を忘れずに」
ということですね．
■著者データ
[ウディ・ダーハン (Udi Dahan)]
"The Software Simplist"として知られる．
ソフトウェアのアーキテクチャと設計のエキスパートとして，
世界的に有名な人物である．
彼はMicrosoftの"Solutions Architecture"と
"Connected Systems"のMVPを4年連続で獲得している．
また，International .NET Associationが認定する，
ヨーロッパ33人のエキスパートの一人でもある．
International Association of Software Architectsのために
トレーナーや執筆活動などを行なっている他，
SOA，Web Services, XMLに関するDDJ推薦の"Guru"でもある．
コンサルティングや講演，トレーナーの時間以外では，
オープンソースの.NETエンタープライズサービスバスとして特によく知られる
NServiceBusの開発リーダもしている．
ブログも参照のこと．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
