В дополнение к предыдущей статье про современную разработку в целом хочу отдельно поговорить про фронтенд-разработку интерфейса пользователя. Если бэкенд-разработка еще как-то напоминает до-web-овские подходы и стоит на плечах титанов – объекты, наследование, то фронтенд – это тихий ужас, никак не могу с этим смириться.
Прежде всего, фронтенд – это винегрет из html-кода разметки внешнего вида web-страницы и исполняемого кода на языке JavaScript. Это дьявольское изобретение, в котором исполняемый код намертво привязан к элементам оформления страницы. Эта бутербродная сущность влияет на всё, включая сложность переиспользования кода даже в похожих по стилю и поведению элементах управления. Внешний вид и поведение элементов управления – кнопок, списков, выпадающих меню - могут быть схожи, но все-таки слегка друг от друга отличаются, поэтому любимый прием фронтенд-разработчика – копирование и вставка кусков кода.
Запутанный и многократно задублированный спагетти-код, который предан анафеме на бэкенде и всеми силами оттуда выпиливался – норма для фронтенда. На бэкенде принято переиспользование кода – если во фрагменте кода обнаружена ошибка, то она правится один раз и ошибка устраняется везде. Если же тестировщик обнаружил проблему в одном из типовых элементов на фронтенде, то фронтенд-разработчик просто поправит ошибку ровно там, где её нашли, и совершенно не будет заморачиваться над тем, чтобы править её во всех других аналогичных элементах – похвалить его за это никто не похвалит, а только будут пилить, чего так долго возишься.
Сценарии использования вместо продумывания умных алгоритмов «вживляются» в голову фронтенд-разработчика. На форме десять элементов управления – кнопки, закладки, элементы перемотки и куча всего. Если пользователь последовательно нажмет элементы управления в том порядке, который предусмотрел разработчик 1-2-3-4, то программа сработает верно. А что будет, если пользователь захочет нажать их в другом порядке 1-3-2-4? Приведет ли это к сбою в логике работы системы? Вот чем занят фронтенд-разработчик большую часть своего времени, но эти знания очень специфичны. В правильно построенной системе все сложные алгоритмы вынесены на бэкенд, на фронтенде остается только «оживление» интерфейса, это не сильно интеллектуальное занятие.
Ускорение разработки с помощью библиотек? Не, это не наш путь. Библиотеки есть, тот же React или TypeScript, но они создаются не с целью ускорить «строительство» приложения, а с целью слегка смягчить те технологические грабли, по которым ежедневно ходит веб-разработчик. Новые библиотеки выходят каждый день, сообщество яростно бросается их осваивать, но потом наступает резкое охлаждение – быстро становится понятно, что революции не свершилось и добавление новой библиотеки в код приносит небольшое облегчение в работе и добавляет кучу новых проблем.
Еще один интересный нюанс фронтенд-разработки: JavaScript-код, который выполняется в браузере, является интерпретируемым языком. Текст кода преобразуется в интерпретатором браузера в машинный исполняемый код построчно в процессе выполнения – программа-интерпретатор прочитала одну строку, перевела её в машинный код, код выполнился в процессоре, перешли к следующей строке и так далее. Это жутко медленно и съедает массу памяти – вот откуда у современных браузеров такие аппетиты, вот на что расходуются вычислительные мощности современных процессоров. Интерпретируемые языки типа Basic или Fortran использовали всегда, я сам учился программировать на Basic, но профессиональная разработка всегда осуществлялась на компилируемых языках – когда программный код сначала полностью проходит стадию компиляции – переводу текста программы в исполняемый код – и только потом запускается на исполнение. Компилируемая программа работает в сотни раз быстрее, чем интерпретируемая, но весь современный веб построен на интепретируемом JavaScript – у меня не укладывается это в голове. Интерпретируемый код в промышленных системах в 21 веке – это нонсенс!
Отдельная тема – автоматические тесты кода, которые прогоняются в среде разработки при обновлении версии программного кода. Они успешно применяются в стабильной бэкенд-разработке и дают уверенность в том, что обновление не «сломает» уже имеющуюся функциональность, у пользователя не перестанут работать те функции, которыми он привык пользоваться. Для фронтенда автоматические тесты кода практически неприменимы из-за своей хрупкости – любое изменение внешнего вида или функциональности любого элемента ломает автоматические тесты, их нужно заново переписывать. Ручное тестирование – наше всё, «увлекательная» работа тестировщика по многократному «прокликиванию» элементов интерфейса не имеет альтернатив. А еще есть куча браузеров и их версий, везде всё должно работать одинаково – (цикл) продолжайте прокликивание после каждого обновления.
Я искренне надеюсь, что в ближайшем будущем web-разработка будет автоматизирована, люди перестанут тратить свое время на это. Сообщения в последнее время относительно возможностей систем с нейронными сетями типа ChatGPT вселяют в это уверенность. Из-за бардака в веб-разработке мало кто из программистов остается там после 30 лет – до тридцати хаос кажется естественным, а после не вызывает ничего, кроме раздражения. Не отдавайте своих детей учиться на веб-разработчика – это прививает дурные манеры в части программирования и не дает возможности уверенно смотреть в будущее.
Следите за новостями в telegram-канале t.me/softprofy
Мой курс для профессионалов разработки программного обеспечения: profysoft.ru
