Разработка новых проектов – это, безусловно, самое интересное занятие для всех. Поэтому легко забыть, что большая часть работ по разработке — это на самом деле обслуживание. И каждая новая строка кода, которую вы пишете, означает, что нужно поддерживать больше кода. Почти все кодовые базы, которые я рассматриваю, имеют значительный технический долг. И долг начинает накапливаться с того момента, как вы начинаете программировать.
Обратный отсчет до Рождества 2023 года: 12 распространенных ошибок в Optimizely CMS — и как их избежать
Этот пост является частью серии «Обратный отсчет Рождества до 2023 года», в которой я каждый день в течение последних 12 дней перед Рождеством просматриваю список 12 наиболее распространенных и опасных ошибок, которые я обычно вижу в реализациях Optimizely (EPiServer) CMS 12. Если вы хотите узнать больше и, возможно, оценить свой собственный сайт, не стесняйтесь обратитесь к нам здесь, в CodeArt.
Вот ссылки на все публикации этой серии по мере их публикации:
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
Ой-ой, Рождество приближается, осталось всего 8 дней! Вы уже сделали все покупки подарков? Если нет, то вам лучше расставить приоритеты. Если все заказано онлайн, вы можете расслабиться и прочитать дальше, и позвольте мне немного вас побеспокоить…
Потому что еще одна постоянная ошибка, которую я вижу снова и снова (и часто в нее попадаю), — это опасность забыть поддерживать свою кодовую базу.
Да, я знаю. Написание нового кода — это весело, с чистого листа — это весело и полезно. Вы станете волшебником, который творит чудеса и впечатляет всех. Погашение технологического долга и поддержание кода вряд ли приведут к увеличению вашей личной базы поклонников, за исключением тех, на кого влияет качество, или тех, кто знает о последствиях.
Некоторые основные шаги по поддержанию вашей производственной кодовой базы могут быть следующими:
- Регулярная проверка журнала AppInsights и/или Episerver на предмет сбоев или медленного ответа. Я знаю, обычно это не та задача, которую вы ставите на своей scrum-доске каждый спринт. Но так и должно быть.
- Регулярно обновляйте CMS (+коммерция + дополнения) до новых минорных версий (рекомендую не реже, чем раз в 3 месяца)
- Установите некоторое время для каждого спринта, чтобы уменьшить количество предупреждений и жалоб на Sonarcloud.
- Проводите частые проверки кода и договаривайтесь о стандартизированной архитектуре.
- При создании нового кода всегда учитывайте, существует ли более стандартизированный способ (или надстройка), который может сделать это лучше и удобнее в сопровождении.
- Регулярно проверяйте наличие уязвимых зависимостей внешнего интерфейса и пакетов nuget и обновляйте их.
- Проверьте Lighthouse (или аналогичный инструмент) на наличие нескольких важных URL-адресов на вашем сайте и сравните их с исторической тенденцией. Поставьте себе задачу по их улучшению, когда это возможно.
Многие из вышеперечисленных задач можно в некоторой степени автоматизировать (или, по крайней мере, автоматически напоминать о том, что вам следует сделать), и я настоятельно рекомендую это сделать.
Я предпочитаю использовать Lighthouse для таких важных задач, как отслеживание общего качества работы браузера, его производительности и соответствия требованиям. Нитеко Инструмент мониторинга производительности, но я знаю, что существует множество инструментов, которые могут сделать что-то подобное.
Очень полезно иметь возможность детализировать измерения веб-производительности и внимательно сравнивать их с предыдущими измерениями, а также наблюдать за развитием событий с течением времени.
«Хорошо, мы добьемся большей производительности, меньшей уязвимости и большей стабильности», — слышу я крик вашего менеджера проекта, — «но что нам действительно нужно, так это новые функции, чтобы постоянно удивлять наших посетителей. Мы не можем тратить время на код, который нам нужен». я уже написал».
Что ж, если вы не будете поддерживать код, время реализации новых функций будет становиться все дольше и дольше – и в конечном итоге всем настолько надоест кодовая база, что вам придется все выбросить и начать все сначала. Наличие хорошей основы — лучший способ эффективно создавать новые интересные функции и хороший веб-интерфейс, но, к сожалению, этому редко уделяется достаточно внимания.