Як мають бути структуровані великі програми JavaScript?

Нещодавно мені показали деякі додатки JavaScript, написані для OBIEE Mobile App Developer, а також деякі власні бібліотеки для різних проектів.

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

Довжина сценаріїв впливає не тільки на читальність та безперебійність, але й на загальне розуміння людиною способів роботи програми.

Як структуровані великі програми? Якісь загальні шаблони дизайну OOP для цього?

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

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

Працюючи над великими проектами, вони також можуть бути корисними:

• Якщо можливо, перейдіть на TypeScript або ES6.
• Написати модульний код. Існують різні способи та сторонні бібліотеки, але будь-який з них краще, ніж нічого.
• Використовуйте систему запуску завдань / побудову для автоматизації завдань.
• Читайте про шаблони дизайну . Це може бути гарним початком. Як я вже говорив вище, шаблон модуля розкриття дуже корисний, особливо якщо ви думаєте, що вам потрібен час для освоєння всіх популярних моделей.
• Пишіть одиничні тести . Робота з динамічною мовою може бути складнішою. Тестування важливих частин вашої програми може заощадити багато часу.
• Використовуйте IDE або текстовий редактор, який може допомогти вам як у написанні коду, так і в пошуку помилок. WebStorm - хороший вибір. Піднесений текст теж.
• Якщо ваш IDE не пропонує налагоджувач, спробуйте освоїти налагоджувач улюбленого веб-браузера.
• Використовуйте бібліотеки. Залежно від характеру проекту, спробуйте використовувати найкращий сторонній код, який ви можете знайти. Якщо ви пишете веб-додаток, подивіться на Angular , React та старий goodbone.js . Якщо ви пишете додаток Node.js, то знайдіть свій час на пошук у сховищі NPM . Ви здивуєтеся, скільки пакетів вже роблять те, що ви тільки збиралися зробити.
• Навіть якщо ви єдина людина, яка працює над проектом, все-таки використовуйте систему контролю версій на зразок Git та дотримуйтесь стандарту кодування, який не надто суворий та висловлюваний, але все ж забезпечує хороший орієнтир, до якого також будуть раді ваші товариші по команді слідувати.
• Навіть якщо ви вибрали TypeScript або ES6, все ще розуміючи OOP без класу JavaScript, Prototypal OOP може бути корисним, особливо під час налагодження.

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

Для мене це просто мова, яка змінилася, на краще чи на гірше, але не парадигма. JavaScript, за всіма його помилками та розладами, є приємним поєднанням функціонального та стилю OOP. Речі до цього часу добре спрацювали.

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

Звичайно, це дуже різниться від проекту до проекту, але загальноприйнята практика полягає в тому, що для речей, які мають функціонувати як бібліотеки або модулі, розміщувати їх в єдиний великий файл і використовувати інкапсуляцію для запобігання його внутрішнього ("приватного") ) інтерфейс від витоку назовні. Також корисно для розробників, які бажають використовувати бібліотеку / модуль - один файл, який потрібно додати до конфігурації програми або фрагменту заголовка замість цілої ієрархії папок і файлів для копіювання та вставки. Це також відображає той факт, що при мінімізації та згуртуванні на виробничому майданчику, швидше за все, всі вони будуть об'єднані в один файл, щоб зменшити кількість HTTP-запитів.

Ваш власний код програми не повинен дотримуватися цієї практики, і він, ймовірно, не повинен. Оскільки ваш додаток є єдиним, хто його використовує, вам потрібно додати файли лише один раз і, ймовірно, можна розраховувати на платформу, щоб обробляти мінімізацію та пакетну групування для вас.

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

Що стосується того, як реалізуються класи для цих модулів, він дещо відрізняється від OOP в основній механіці, але не такий різний на поверхні. ES6 навіть представив classключове слово, тому воно повинно виглядати досить звично. Цю статтю про MDN корисно почати: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Я використовую (Петрі) чисті елементи та анотації, щоб організувати або "структурувати" програмне забезпечення для моїх програм PDF-форм - програм JavaScript, які використовують API Acrobat / JavaScript. Можливо, це може бути корисним у вашій ситуації.

Діаграма використовується для встановлення відносин введення-виведення чистих елементів та двох форм перегляду анотацій. На основі діаграм і представлень форм можна систематично створювати програми JavaScript для додатків PDF-форм. Таким чином, «зчитування» вихідного коду зводиться до перевірки відповідності йому специфікаціям: діаграмі та двома видами форм.

Реалізація мого програмного забезпечення використовує конструктори та прототипи. Якщо продуктивність стає проблемою, то заміна прототипів членами екземпляра може покращити продуктивність за рахунок більшого використання пам'яті. Також використовуються масиви. Якщо продуктивність стає проблемою, використовуються прямі посилання.

Деякі властивості створюються за допомогою eval; для об’єктів з дуже великою кількістю властивостей це зменшило б кількість коду у вихідному файлі - і зменшило б кількість набору тексту програмістом.

Ще можливо і рекомендується писати JavaScript так, як ви звикли. Ось гарна книга, яка переглянула найважливіші шаблони дизайну в JavaScript.

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

Існує також багато фреймворків JavaScript, де головна мета - це можливість розподілити код на різні файли та модулі. Якщо конкретна рамка, в якій ви працюєте, вимагає, щоб ви мали весь код в одному файлі, тоді вам обов'язково слід переключитися.