Проблема 1. Рост объёма кода

↑

▷ Содержание

⇐ ПредыдущаяСтр 2 из 5Следующая ⇒

Подумаем, как появляется эта проблема, и к каким последствиям она приводит.

Представим, что нам поступила задача — разработать простое веб-приложение — таймер. Задача действительно очень простая. Нам нужно одно поле, одна кнопка и простой скрипт из нескольких функций.

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

Сложной ли получилась кодовая база нашего проекта? Очевидно, что нет. В зависимости от оформления, у этого веб-приложения появляются варианты вёрстки или стилей. Но мы сейчас говорим в первую очередь о логике, то есть о JavaScript, куда также входят CSS и HTML.

Где хранить JavaScript:

l в самом HTML файле;

l в отдельном файле, чтобы подключать его как внешний скрипт, используя тег <script src>.

Действительно, пока у нас мало логики, это не критично.

Но к нам приходит заказчик и говорит: «Просто таймер — это хорошо, но наши пользователи хотят больше опций. Требуется добавить функцию сброса времени, сохранять отрезки времени, считать интервалы, и вообще, хорошо бы добавить ещё и сигнал при окончании времени с возможностью отключать звук и выбирать мелодию».

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

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

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

Хорошо, поделим наш код на несколько файлов.

Возьмём приблизительную структуру проекта:

1. В css/main.css хранятся стили нашего веб-приложения.

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

3. Файлы common.js и main.js содержат общий код нашего приложения.

4. В папке media находятся звуки для нашего приложения.

5. index.html содержит вёрстку нашего приложения и соединяет все файлы.

Бесспорно, есть и другие варианты организации структуры нашего приложения, а для каждой части инструментария (таймер, секундомер) можно завести свой.html файл. Но представим, что все файлы у нас подключаются в один общий html-файл и меняются динамически (без перезагрузки страницы), когда пользователь нажимает кнопки соответствующей функции.

Итак, в наш index.html требуется подключить все js-файлы:

Получилось много файлов, и появился риск забыть подключить один из них.

Мы разместили наши файлы в самом конце body. Это позволит быстрее загрузить и отрисовать вёрстку приложения (построить DOM-дерево). Наши скрипты без него всё равно бесполезны, поэтому нужно постоянно обрабатывать событие DOMContentLoaded.

Браузер последовательно ожидает загрузку и исполнение каждого указанного в теге script-файла. Поэтому, если они находятся в секции head, есть риск «блокировки» отрисовки всей страницы, пока каждый из файлов не загрузится и выполнится. Например, если у пользователя слабое интернет-соединение или медленное устройство (смартфоны).

Хорошее решение — указать атрибут defer. Он гарантирует, что:

l скрипт выполнится только после окончания парсинга DOM, но до события DOMContentLoaded;

l и в том порядке относительно других defer-скриптов, в каком те указаны в исходном коде.

Помните наш калькулятор дат? Тот самый, что должен учитывать таймзоны и високосные года? Что-то не хочется писать всю логику расчёта самостоятельно — сложная логика и условия. Очень легко ошибиться.

Ничего страшного, воспользуемся трудами сторонних программистов и применим стороннюю библиотеку для работы с датами Luxon. Для этого подключим её в наш проект.

Отлично, мы сделали это! Теперь, воспользовавшись атрибутом defer, наши скрипты не заблокируют поток отрисовки вёрстки.

Обратите внимание на файл js/main.js. Предполагается, что он содержит какой-то основной код нашего приложения. Его задача — выполняться сразу, а не ждать окончательной загрузки DOM-дерева.

Итак, решили ли мы проблему большого объёма кода в одном файла? Да, но из этого решения вытекают новые проблемы.

Познавательные статьи:



Коммуникативные барьеры и пути их преодоления

Рынок недвижимости. Сущность недвижимости

Решение задач с использованием генеалогического метода

История происхождения и развития детской игры