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

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

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

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

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

И дело не только в легком дискомфорте. Продуктивности команды разработчиков могут помешать инструменты прошлых лет. Хотя старые способы ведения дел не забыты, они могут стать немного заржавевшими из-за отсутствия знакомства.

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

При этом небольшие первоначальные затраты часто полностью оправдывают себя и окупятся в будущем.

Пример из реальной жизни: предпосылка

Позвольте мне рассказать вам историю о такой ситуации. Все началось с того, что в 2013–2014 годах мы разработали веб-приложение AngularJS для одного из наших клиентов.

Для тех, кто интересуется технологическими тонкостями, это время, когда AngularJS набирает обороты и только что достиг версии 1.2. Bower и npm используются совместно для извлечения зависимостей (а некоторые даже загружаются вручную *удушье*). Less или Sass используется для стилей письма. Задачи разработки выполняются с помощью Grunt, и мало кто вообще слышал о таком понятии, как Gulp.

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

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

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

Пример из реальной жизни: решение

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

Внимание! С этого момента этот раздел становится немного техническим. Если вас не интересуют подробности, можете пропустить следующие 4–5 абзацев.

Медленное время сборки было, по крайней мере, частично результатом общей структуры проекта. Приложение было частью большого многомодульного проекта Maven, состоящего из множества более или менее связанных проектов. Запуск таких инструментов, как npm и Grunt через Maven, был громоздким и занимал больше времени, чем необходимо.

Рассматриваемое приложение было очень слабо связано с другими частями основного проекта; единственной реальной зависимостью был REST API. Было несложно (оглядываясь назад) разделить его на собственный проект, основанный на легких узлах. Таким образом, его можно было построить параллельно с другими модулями всего комплекса, сократив на несколько минут общее время сборки.

Старый конвейер разработки использовал для управления зависимостями как npm, так и Bower. Это было упрощено до использования npm, как это рекомендуется в настоящее время.

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

Последним дополнением стало включение современных функций языка JavaScript в виде поддержки ES2015+. Это было достигнуто за счет использования babel и webpack.

Благодаря этим небольшим изменениям опыт разработчиков значительно улучшился. Общий процесс стал более упорядоченным, с меньшим количеством ручных операций, и время, необходимое для начала работы, значительно сократилось. Кроме того, новые языковые функции JavaScript упрощают написание более лаконичного кода. И, по словам основателя XP Рона Джеффриса:

Лучший способ реализовать код быстро — это реализовать его меньше. Лучший способ уменьшить количество ошибок — реализовать меньше кода.

Некоторые вещи (например, модульные стили) здесь были намеренно опущены. Однако изменения в общей структуре проекта значительно упрощают включение их на более позднем этапе.

В заключении…

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

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

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