Рекомендации для библиотек и пространств имен

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 и т. Д.

Внутри библиотеки JS, например, у меня есть WebGL, Canvas, JQuery, Regular JS classes (если мы их будем называть).

Как вы можете видеть, что это немного беспорядок, поэтому я пытаюсь узнать, что делают другие, поэтому я сделал список быстрых вопросов:

КАК Handle:

• Различные языки?
• Различные платформы (это то, что называется? WebGL, Canvas, JQuery и т. Д.)?
• Различные проекты
• внешних библиотек и зависимостей

Как я исследовал, я думал о Google, и я спрашивал себя, как они обращаются с их Google Maps библиотеки, например, они должны иметь общую библиотеку Google с кучу полезных функций, но есть также файлы только для Карт Google, и у них есть бэкэнд, возможно, PHP и JS-интерфейс, так как все это управляется?

Спасибо за вашу помощь: D

PS. Я использую Git для управления версиями работы

Answer 1

Я пишу это, потому что вы хотели знать, что делают другие. Вот что я делаю. Я бы не стал утверждать, что это «лучшая практика».

1) Когда прошли годы, я понял, что помню свои библиотеки через проекты. Потому что проекты были актуальными задачами, а не библиотеками.

2) Мы больше не программируем на одном языке. Тенденция к облачным серверам и приложениям приходится решать с несколькими платформами на нескольких языках.

3) Я видел, что каждый раз, когда я создаю приложение, если он становится лучше, коды платформы начинают отражать язык кодирования и независимый от структуры (насколько это возможно) функциональный сходство.

4) Когда вы оглядываетесь назад на проект, он должен быть готов к повторной работе или любая компиляция должна быть возможной без переопределения структур каталогов и т. Д. Поэтому, если вы используете код конкретной платформы, вы должны сделать это согласно требования к кодированию платформы, например, почти абсурдно принудительно хранить код Android в другой структуре каталогов, а затем затмить.

Так как я это делаю:

Главная точка входа всегда 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 будет отражать реализацию, язь и платформы Зависимость от. Так что нет great cure that fits all не существует ...

---

Теперь, наконец, у меня есть каталог: проекты, а под ним у меня есть каталоги лет, и каждый год у меня есть проекты, которые я сделал в этом году ...

Надеюсь, это поможет.

Answer 2

Когда дело доходит до проекта структуры мой совет:

1) Будучи в соответствии с вашей структурой является более важным, чем точное структуры вы используете

2) не изобретайте колесо - с использованием структуры выложена существующей структуры имеет смысл

Что касается ваших конкретных вопросов:

1) Различные языки

Я предполагаю, что вы имеете в виду человеческие языки, поскольку мы говорим о javascript здесь. Я думаю, что интернационализация должна быть отделена от структуры вашего кода. Есть много существующих библиотек, которые могут обрабатывать его, и он был рассмотрен подробно в этом вопросе: https://stackoverflow.com/questions/9640630/javascript-i18n-internationalization-frameworks-libraries-for-client-side-use

2) Различные платформы

Мне нравится упаковать код вертикально, а не горизонтально. Другими словами, я думаю, что код должен быть упакован по домену, а не по техническому уровню. Это хорошее объяснение этому в книге Domain Driven Development.

3) Различные проекты

Я бы предположил, что это, как правило, будет обрабатываться неявно тем, что код в различных исходных деревьев. Тем не менее наличие корневого пространства имен, вероятно, решает это и является хорошей практикой, поскольку оно имеет наименьший глобальный след.

4) Внешние библиотеки

Я хотел бы посмотреть на CommonJS - это условность для загрузки Java-библиотеки и становится повсеместным стандартом. http://www.commonjs.org/