詳細設計、製造、UTあたりの工程からプロジェクトに参加すると、
既に適用する共通ライブラリって決定されていて、
便利なオープンソースのライブラリの適用が出来ない状況が多々あるよね。

しかも、利用するフレームワーク（特に企業独自に開発したヤツ）によっては、
包括したユーティリティクラスなんて、ほぼ存在しない場合だってあるのに。

こんな場合に、なんの対策も講じないと、
同じようなコードを何度も書いたり、コピペしたりで、
仕様変更なんかされたら、即炎上。

そんな時に、社内で作成したライブラリの共有を円滑に進める必要があると思うんだ。
参考にしたのは「WEB+DB PRESS vol.38 無駄なコードを書かない技術」


ボトムアップルール
開発者自身が、開発中に「こんなライブラリがあったら便利」と気が付いたとき、
共通ライブラリを作成する場合のルール。

『書く前に開発メンバー全員に尋ねる。』

ポイント
　気軽に聞いてすぐにレスポンスをもらえる環境を準備しておく。
　メーリングリストより、インスタントメッセンジャーを利用した方がベター。
メリット
　開発メンバー間のコミュニケーションが促進される。
デメリット
　開発メンバーが分散している場合に適用しにくい。

トップダウンルール
既に適用している共有ライブラリについて、適用箇所を開発者に任せている場合、
共有ライブラリと共に、「ドキュメント」「サンプルコード」を提供するルール。

『書く前に共有ライブラリが存在しないか確認する。』

ポイント
　提供されている共有ライブラリを、俯瞰できる環境を準備しておく。
　Wikiベースのライブラリ共有サイトを使う方法が挙げられる。
メリット
　開発メンバーが頻繁に参照することにより、類似のライブラリ作成が抑制される。
デメリット
　運用方法を決定しておかなければ、ドキュメントが陳腐化してしまう。


情報共有ツールの活用（例えばWiki）
・運用ルールを決めておく
１．モジュールを作成する場合は、Wikiを参照し同機能のモジュールが無いことを確認する。

２．再利用性の高いと思われるモジュールを作成したら、
　　共有Wikiの所定のページにその仕様を明記する。
　作者名(問合せ先)
　ライブラリの概要
　サンプルコード
　説明
　機能一覧

３．毎朝のミーティングで追加ライブラリの周知を行う。


社内向けライブラリ作成のコツ
『基本』
・ライブラリは相互依存しないようにする。
・ライブラリを更新できるメンバを限定する。
・一度公開したライブラリのインターフェイスを変更しない。
・ユーティリティクラスのメソッドは、基本的にstaticメソッドとする。
『オープンソース活用』
・オープンソースのユーティリティ系クラスのソースコードを読む
・オープンソースのモジュールの一部を真似て自作する。
・パッケージ、クラス、メソッド、変数などネーミングを真似する。


重要なのは『ルール』を決め、遵守することで、
開発者自身に『価値』が与えられること。