Практический подход к сохранению jQuery в актуальном состоянии?

Question

Некоторые из проектов, над которыми мы работаем, имеют сильные корни в jQuery 1.4.2 или более ранних версиях, и где-то между отсутствием предела производительности (или синтаксического сахара) последних выпусков, унижением использования устаревших методов и дискомфорт при развертывании 3+-летней версии активно поддерживаемой библиотеки, обновление теперь неминуемо.

Каковы некоторые популярные в сообществе практики, которые мы могли бы принять/повторно посетить, чтобы обеспечить плавное развертывание (т. Е. Сосредоточиться на проблемах с неясной совместимостью, поднять глобальные регрессии, перефразировать некоторые из старых кодов ...) ? Как их лучше всего интегрировать в SDLC для будущих обновлений? Каков разумный график обновления для библиотеки, такой как jQuery (я не ожидаю значительных выигрышей или оправданных затрат для этого при каждом выпуске, но раз в 6-12 месяцев вполне может быть разумным)?

Answer 1

Чтобы действительно ответить на ваши три вопроса, вот некоторые вещи, которые я сделал или, по крайней мере, рекомендую:

Лучших практик для плавного развертывания обновления

• Проведите тесты. Это могут быть модульные тесты для ваших тестов JS и/или браузера. Они должны охватывать, по крайней мере, самые типичные и самые сложные функции, используемые в ваших проектах. Если у вас нет тестов, напишите их. Если вы не хотите писать тесты, передумайте. Если вы reeeeally не хотите писать тесты, по крайней мере, есть список вариантов использования, которые кто-то сможет выполнить вручную.
• Убедитесь, что все ваши тесты прошли до обновления.
• Прочитайте примечания к выпуску для каждые (основная) версия между версией, которую вы используете сейчас, и самой последней версией. См. Также категории Removed и Deprecated в документах API. Если какой-либо из ваших кодов использует jQuery UI, посмотрите также эти примечания к выпуску и upgrade guides для межстраничных версий. По мере того, как вы это делаете, обратите внимание на то, что вам, вероятно, придется изменить в вашей кодовой базе (возможно, с большим использованием grep).
• Если текущая версия jQuery для вашего проекта> = 1.6.4, также рассмотрите возможность использования jQuery Migrate plugin для дальнейшей оценки требуемой работы.
• Определите, какой вариант вы хотите стать целью обновления, основываясь на работе, необходимой для ее работы, независимо от того, используете ли ваш проект какие-либо сторонние библиотеки, для которых требуется определенная версия jQuery, другие факторы, которые вы можете рассмотреть, и т. Д.
• Познакомьтесь с вашей командой, чтобы просмотреть список изменений, которые необходимо внести в вашу кодовую базу, и соответствующим образом разделить/назначить работу. Возможно, напишите некоторые скрипты или другие инструменты, чтобы помочь. Если у вас его есть, также может быть необходимо обновить документ руководства по стилям и рекомендации по кодированию вашей команды. Решите одноразовые (рекомендуемые) или скользящие обновления, если это возможно + желательно. Придумайте подходящую стратегию выпуска. (Я рекомендую не выпускать обновление как часть другого несвязанного большого изменения в вашу кодовую базу, поэтому вам легко откат, если вам нужно.)
• На протяжении всего процесса обновления постоянно выполняйте свои тесты. При тестировании вручную всегда проверяйте консоль браузера на наличие новых ошибок. Напишите новые тесты, которые охватывают непредвиденные ошибки.
• Когда все тесты проходят, определите, как вы хотите развернуть - если это сайт, все пользователи одновременно или в процентах за раз и т. Д. Для библиотеки или другого проекта, возможно, вы выпустили бета-версию/bleeding edge, которую вы можете позволить своим более амбициозным пользователям протестировать вас в дикой природе.
• Документируйте все, что вы только что сделали, чтобы это было проще в следующий раз.
• [Profit.]

Как интегрировать обновления в нормальный рабочий процесс

• Опять же, тесты. Удостоверьтесь, что у вас есть они. Удостоверьтесь, что они хороши, поддерживаются и охватывают большую часть вашей кодовой базы и случаев использования. Настоятельно рекомендуется установить непрерывную интеграцию, чтобы автоматизировать работу этих тестов.
• Подумайте о том, чтобы ваша команда создала и согласилась следовать руководству или стандарту стиля кодирования. Это облегчит в будущем поиск устаревших вызовов функций или конструкций, поскольку каждый будет следовать аналогичным шаблонам кодирования. Полезными могут быть такие инструменты, как скрипты, фиксации фиксации, утилиты статического анализа и т. Д., Чтобы обеспечить хороший или вынюхать плохой стиль кодирования (в зависимости от команды).
• Изучите и, возможно, решите использовать диспетчер пакетов, например NPM или bower, для управления версиями jQuery и другими сторонними библиотеками, которые вы можете использовать, которые зависят от него. (Вам все равно нужно будет сохранить свой собственный JS-код и пройти почти такой же процесс, как описано выше.)
• Опять же, как только вы закончите версию 1.6.4, убедитесь, что плагин Migrate является частью рабочего процесса обновления ,
• Оцените, что сработало с начального большого процесса обновления, что не получилось, и извлеките из него общий процесс, который лучше всего работает с вашим текущим рабочим процессом. Независимо от того, планируете ли вы обновлять каждый раз, когда есть новая версия, будут выполняться текущие задачи обслуживания и привычки, которые вы, вероятно, захотите сохранить в качестве общей практики наилучшего развития.

Разумного график обновления

Это по существу вопрос/управления рисками CBA. Вы должны взвесить некоторые вещи:

• Там должно быть не переломные изменения API в пределах одной и той же основной версии, так что вы должны вообще быть в состоянии обновить до самой последней младшую версию с минимальными усилиями, без рефакторинга обязательный.Это предполагает, что у вас есть и поддерживайте хорошие тесты, которые вы можете использовать в своих проектах, прежде чем решите, что все достаточно хорошо для развертывания.
• Для обновления основных версий требуется больше исследований, больше рефакторинга и более тестирования. После этапа исследования вы должны провести анализ затрат и результатов модернизации.
• Это может иметь большое значение, но если какой-либо из ваших проектов является веб-сайтом с множеством пользователей, то какова будет стоимость того, чтобы все ваши пользователи загрузили по существу все измененные файлы JS на вашем сайте в следующий раз они посещают его (вместо того, чтобы придерживаться более старых версий, которые, вероятно, все еще кэшируются в их браузерах)?
• Решение об обновлении всегда должно быть субъективным. Мало или майор, вам все равно придется оправдывать каждый раз, будет ли какое-либо обновление стоить того. Всегда читайте примечания к выпуску. Исправляет ли он security vulnerability или ошибка, связанная с проблемами, которые вы или ваши пользователи испытываете в настоящее время? Будет ли это значительно улучшать производительность вашего проекта (не забудьте проверить его позже)? Это значительно упрощает шаблон кодирования, который вы использовали, позволяя писать ваш код более чисто и легко? Есть ли сторонняя библиотека, которую вы хотите использовать, которая зависит от этой более новой версии? Существуют ли уже сторонние библиотеки, которые зависят от версии старше? (Если это так, возможно, эти библиотеки могут быть обновлены в ближайшее время для работы с более новой версией?). Вы уверены в своих тестах и ​​процессе QA, что обновление потребует разумного объема ресурсов разработки и не приведет к серьезным регрессиям? Вы думали, что в конечном итоге выкинуть jQuery с чем-то другим? И т.д.

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

Answer 2

Это стоит посмотреть в: https://github.com/jquery/jquery-migrate/#readme

Этот плагин может быть использован для обнаружения и восстановления API, или функции, которые устарели в JQuery и удалены в версии 1.9. Дополнительную информацию о сообщениях, которые генерирует плагин , см. В warnings page. Для получения дополнительной информации об изменениях, сделанных в jQuery 1.9, , см. upgrade guide и blog post.

Answer 3

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

Если вы не хотите устанавливать часы/дни/недели разработки, тестирования и исправления ошибок, с возможностью нарушения функциональности, ориентированной на пользователя, вы не должны обновлять, чтобы использовать новейший способ объявления обработчиков событий. Это не повредит вам. И обычно это рискованно. Это приводит к затратам команды разработчиков. Вы уже это знаете. Рефакторинг, особенно когда нет очевидного риска для проекта, в целом трудно оправдать для менеджеров. И вы должны дважды проверить свои мысли, чтобы убедиться, что если новый jQuery в уже работающем коде будет иметь значение.

Теперь, если вы работаете над созданием новых страниц на существующем сайте, вы можете включить новую версию в эти области. Но это будет иметь последствия: предположим, что вы и ваша команда, помимо разработки новой части сайта, также должны поддерживать часть, использующую старую. Все должны знать о конкретной версии jQuery, с которой они пишут свой код.

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

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

Answer 4

Для того, чтобы держать в курс в дереве развития, я рекомендую использовать src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (полную не-уменьшенную версию, которая позволяет для облегчения отладки)

Затем, когда вы идете опубликовать, просто заменить его с конкретным (в настоящее время http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js). Это дает возможность улучшить кэширование на стороне клиента и использовать чью-то пропускную способность.

Если кеширование вызывает меньшую озабоченность, чем обеспечение того, что оно автоматически получит исправления для этой версии с малой версией, вы можете использовать только основную и второстепенную версию, например: http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (Примечание: в google пока нет серии 1.9 но серии 1.8 - до 1,8.3). Поскольку эти обновления периодически обновляются для исправлений ошибок, они не получают кеширования, как выпуски, специфичные для версии.

Answer 5

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

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

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

Например: как у вас есть имя метода update_var(); его захода в другой метод другого сервиса, как $a = newlib::check_update();. Затем, создав библиотеки, вы должны изменить основную библиотеку функции вашей и основной библиотеки задействованного сервиса.

Answer 6

Ребята из Twitter решили эту проблему довольно хорошо.

http://github.com/twitter/bower

Он делает то, что он говорит на олово - это менеджер пакетов для веб (и что включает в себя сохраняя JS файлы, такие как JQuery до даты)