Как большие JavaScript-приложения должны быть структурированы?

Недавно мне показали несколько плагинов JavaScript, написанных для разработчика мобильных приложений OBIEE, а также несколько пользовательских библиотек для различных проектов.

Исходя из опыта ООП, я немного запутался в структуре этих проектов. Я вижу файлы длиной в тысячи строк. Я привык разбивать вещи на файлы и классы, но я понимаю, что это другая структура - например, размер файла - это проблема, но должен быть лучший способ сделать все это?

Длина сценариев влияет не только на удобочитаемость и удобство обслуживания, но и на общее понимание человеком того, как работает программа.

Как структурированы большие приложения? Какие-нибудь общие модели ООП для этого?

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

Шаблон раскроя модуля, тем не менее, должен дать вам хороший способ разбить большие файлы и логически организовать их; Однако, когда вы работаете с любыми шаблонами проектирования в JavaScript, имейте в виду, что это может привести к путанице. Попробуйте использовать это , новый , прототип , .call()и с .apply()умом.

Работая над большими проектами, они также могут быть полезны:

• Если возможно, переключитесь на TypeScript или ES6.
• Напишите модульное код. Существуют различные способы и сторонние библиотеки, но любой из них лучше, чем ничего.
• Используйте Task Runner / Build System для автоматизации задач.
• Читайте о шаблонах дизайна . Это может быть хорошим началом. Как я уже говорил выше, шаблон модуля раскрытия очень полезен, особенно если вы считаете, что вам нужно время, чтобы освоить все популярные шаблоны.
• Написать модульные тесты . Работа с динамическим языком может быть более сложной. Тестирование важных частей вашего приложения может сэкономить много времени.
• Используйте IDE или текстовый редактор который действительно может помочь вам как с написанием кода, так и с обнаружением ошибок. WebStorm - хороший выбор. Sublime Text тоже.
• Если ваша IDE не предлагает отладчик, попробуйте освоить отладчик вашего любимого веб-браузера.
• Используйте библиотеки. В зависимости от характера проекта, попробуйте использовать лучший сторонний код, который вы можете найти. Если вы пишете веб-приложение, взгляните на Angular , React и старый добрый backbone.js . Если вы пишете приложение Node.js, найдите время для поиска в репозитории NPM . Вы будете удивлены, сколько пакетов уже делают то, что вы собирались сделать.
• Даже если вы единственный человек, который работает над проектом, все равно используйте систему контроля версий, такую ​​как Git, и следуйте стандарту кодирования. который не слишком строг и самоуверен, но все же предоставляет хороший ориентир, который ваши товарищи по команде также были бы рады следовать.
• Даже если вы выбираете TypeScript или ES6, все еще понимая ООП без классов JavaScript, ProOtypal OOP может быть полезен, особенно при отладке.

Я разработчик C ++ и начал заниматься веб-разработкой в ​​последнее время. Я портирую большое настольное приложение на веб-среду. Я структурирую свой код JavaScript точно так же, как структурировал код C ++, используя те же шаблоны. У меня всего около 25-30 файлов, но я со временем уменьшу их до 3-5, забивая по мере необходимости и минимизируя их все.

Для меня это просто язык, который изменился, к лучшему или к худшему, но не парадигма. JavaScript, со всеми его недостатками и разочарованиями, представляет собой хорошее сочетание функциональности и стиля ООП. Пока все хорошо работает.

Наконец, одна вещь, которую я осознал на раннем этапе, состояла в том, что JavaScript позволяет писать намного более лаконичный код, чем C ++, поэтому иногда наличие большого количества LOC, происходящих из не-JS-языка, может быть связано с тем, что он придерживается старого способа работы. Как только эта вещь решена, я не вижу ничего, что действительно должно быть другим. Дизайн и алгоритмы, в конце концов, не зависят от языка.

Конечно, он сильно варьируется от проекта к проекту, но общепринятая практика заключается в том, что вещи, предназначенные для функционирования в качестве библиотек или модулей, помещают их в один большой файл и используют инкапсуляцию для предотвращения его внутреннего («частного») ) интерфейс от утечки наружу. Это также полезно для разработчиков, желающих использовать библиотеку / модуль - один файл для добавления в конфигурацию приложения или фрагмент заголовка вместо целой иерархии папок и файлов для копирования и вставки. Это также отражает тот факт, что при минимизации и группировании на рабочем сайте все это, скорее всего, будет объединено в один файл для уменьшения количества HTTP-запросов.

Ваш собственный код приложения не должен следовать этой практике, и, вероятно, не должен. Поскольку ваше приложение является единственным, использующим его, вам нужно всего лишь добавить файлы один раз, и, вероятно, вы можете рассчитывать на платформу, чтобы справиться с минимизацией и комплектацией.

При работе над кодом различные компоненты обычно разделяются на модули, каждый из которых, как правило, реализует отдельный класс, и каждый из них находится в отдельном файле. В процессе производства эти файлы затем объединяются в один файл (отсюда тысячи строк кода, который вы видите), используя что-то вроде Browserify ( http://browserify.org/ ) или RequireJS, чтобы уменьшить количество HTTP-запросов, но и для того, чтобы зависимости загружались в правильном порядке

Что касается того, как реализованы классы для этих модулей, это немного отличается от ООП в базовой механике, но не так уж и отличается на первый взгляд. ES6 даже ввел classключевое слово, поэтому оно должно выглядеть довольно знакомым. Эта статья о MDN полезна для начала: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Я использую (Petri) Net Elements и Annotations для организации или «структурирования» программного обеспечения для моих приложений в форме PDF - программ JavaScript, которые используют Acrobat / JavaScript API. Возможно, это может быть полезно в вашей ситуации.

Диаграмма используется для установления отношений ввода-вывода сетевых элементов и двух представлений формы аннотаций. Основываясь на диаграммах и видах форм, можно систематически создавать программы JavaScript для приложений форм PDF. Таким образом, «чтение» исходного кода сводится к проверке его соответствия спецификациям: диаграмме и двум видам формы.

В реализации моего программного обеспечения используются конструкторы и прототипы. Если производительность становится проблемой, то замена прототипов членами экземпляра может повысить производительность за счет увеличения использования памяти. Массивы также используются. Если производительность становится проблемой, то используются прямые ссылки.

Некоторые свойства создаются с помощью eval; для объектов с очень многими свойствами это уменьшит объем кода в исходном файле и уменьшит количество набираемых текстов программистом.

Все еще возможно и рекомендуется писать JavaScript так, как вы привыкли. Вот хорошая книга, в которой рассматриваются наиболее важные шаблоны проектирования в JavaScript.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

Существует также множество JavaScript-фреймворков, основная цель которых - разделить код на разные файлы и модули. Если конкретный фреймворк, в котором вы работаете, требует, чтобы весь ваш код был в одном файле, то вам определенно стоит переключиться.