ライブラリとネームスペースのベストプラクティス

Question

ライブラリを作成するためのベストプラクティスは何ですか？

私は10年近く前から開発を続けており、私が働いているうちに図書館を建てています。

MYLIB.SomeUtility.utilFunc(); 
new MYLIB.SomeProject.ProjectClass(); //project specific classes 

//Sometimes I have classes that extends external libraries, 
//like JQuery, or KinteticJS objects 
new MYLIB.SomeExternalLibrary.ExternalLibraryClass(); 

マイライブラリは、CSS/JS/PHP/AS3のファイルを持っていますが、私のような彼らの別のライブラリにそれらそれぞれを区切ってきた混乱を避けるために：

私は現在、それを設定している方法は次のパターンに従います。 MYLIB_JSなど...

たとえば、私はWebGL、Canvas、JQuery、Regular JSクラスを持っています（これを呼び出すとします）。

あなたはそれが混乱のビットですので、私が何をしているか他の人を学ぶしようとしているので、私は簡単な質問のリストを作った見ることができるように：

処理する方法を

：

• 別の言語ですか？
• 異なるプラットフォーム（WebGL、Canvas、JQueryなど）
• 異なるプロジェクト
• 外部ライブラリ、および依存関係

私はGoogleの考え研究していた、と私は、彼らが例えば自分のGoogleマップライブラリをどのように処理するかを自問したとして、彼らはとの一般的なGoogleのライブラリを持っている必要がありますユーティリティの束はたくさんありますが、Google Maps専用のファイルもあります。バックエンドにPHPやJSのフロントエンドがあるので、どのように管理されていますか？

ご協力ありがとうございます：D

PS。それは私の助言がある構造を投影するとなると、私はバージョン管理作業

Answer 1

他人のことを知りたいと思っていたので、私はこれを書いています。ここに私がしていることがあります。私はそれが「ベストプラクティス」であると主張しません。

1）何歳になっても、私はプロジェクトを通してライブラリを覚えていることに気付きました。プロジェクトは実際の課題であり、図書館ではなかったからです。

2）これ以上の単一言語のプログラムはありません。この傾向はクラウドサーバに向かい、アプリケーションは複数の言語に対応した複数のプラットフォームに対応する必要があります。

3）私は、アプリケーションをビルドするたびに、コードが良くなると、コーディング言語とフレームワークが（可能な限り）機能的な類似性を反映し始めていることがわかりました。

4）プロジェクトに戻ってみると、再処理の準備ができているか、ディレクトリ構造などを再定義することなくコンパイルが可能でなければなりません。したがって、プラットフォーム固有のコードを使用する場合は、プラットフォームのコーディング要件、例えば、強制的に他のディレクトリ構造にEclipseコードを格納することはおかしくない。

だから私はそれを行う方法：

メインエントリポイントが常にprojectです。 私はプラットフォームに分かれています。 私はプラットフォームのツールとフレームワークに分かれています。

すなわち：各サブセクションについては

TheGreatWebProject 
     |------->Server 
     |   |------>Php 
     |   |    |------>aScaryPhpFrameWork 
     |   |    |------>myPhpLibraries 
     |   |       |-----------> myPhpLib1 
     |   |       |-----------> myPhpLib2 
     |   |------>DotNet 
     |       |------>aScaryDotNetFrameWork 
     |       |------>myDotNetLibraries 
     |          |-----------> DotNetOutputs 
     |          |-----------> myDotNetLib 
     |          |-----------> myDotNetSources 
     |   
     | 
     |------->Client 
     |   |------>Html 
     |   |   
     |   |------>Css 
     |   | 
     |   |------>JavaScript 
     |   |    |-----------> aScaryJsLibrary 
     |   |    |-----------> myJsLib1 
     |   |    |-----------> myJsLib2 
     |   | 
     |   |------>ActionScript3 
     |       |-----------> aScaryAs3Library 
     |       |-----------> swfOutputs 
     |       |-----------> myClient1.fla 
     |       |-----------> myClient2.fla 
     |       |-----------> myAs3AppSrc(in package 
     |          management file structure) 
     |    
     |   
     |------->Extras 
        |------>Locales 
        |------>Documents 
        |------>Images 
        |------>Audio 
        |------>Video 
        |------>Other 

---

subcategorizationsは、実装、IDEおよびプラットフォーム依存を反映します。だから、何great cure that fits allが存在しない...

---

は今、最終的に私は、ディレクトリを持っていますし、その下のプロジェクトは私が年のディレクトリがあり、それぞれの年に私はその年に作られたプロジェクトを持っている...

私はこれが助けてくれることを願っています。

Answer 2

のためにGitを使用します。あなたの構造と一致している

1）正確な構造よりも重要であるあなたは

2を使用します）車輪の再発明をしないでください - 既存のフレームワークによってレイアウトされた構造を使用して、具体的な質問については感覚

を行います

1）異なる言語

ここではJavaScriptについて話しているので、私はあなたが人間の言語を意味すると仮定しています。私は国際化がコードの構造から分離されるべきだと思います。それを扱うことができ、それがこの質問の長さで対処された既存のライブラリがたくさんあります：https://stackoverflow.com/questions/9640630/javascript-i18n-internationalization-frameworks-libraries-for-client-side-use

2）異なるプラットフォームが

私は水平ではなく、垂直方向にコードをパッケージ化したいです。言い換えれば、コードは技術的な層ではなくドメインでパッケージ化されるべきだと私は思います。これについてはDomain Driven Developmentという本でよく説明されています。

3）異なるプロジェクト

私は、これは通常、コードは異なるソースツリーにあるという事実によって暗黙的に処理されるだろうと想像します。それにもかかわらず、rootネームスペースを持つとおそらくこれが解決され、グローバルフットプリントが最小であるため、良い方法です。

4）外部ライブラリ

私はCommonJSを見てしまう - それはjavascriptのライブラリをロードし、ユビキタス標準となってきているための規約です。 http://www.commonjs.org/