Одно из самых распространенных и страшных заболеваний при разработке веб-сайтов часто остается невыявленным и невылеченным в течение длительного времени. Но так и должно быть, потому что последствия пугают. Да, я говорю о синдроме «изобретенного не здесь».
Обратный отсчет до Рождества 2023 года: 12 распространенных ошибок в Optimizely CMS — и как их избежать
Этот пост является частью серии «Обратный отсчет Рождества до 2023 года», в которой я каждый день в течение последних 12 дней перед Рождеством просматриваю список 12 наиболее распространенных и опасных ошибок, которые я обычно вижу в реализациях Optimizely (EPiServer) CMS 12. Если вы хотите узнать больше и, возможно, оценить свой собственный сайт, не стесняйтесь обратитесь к нам здесь, в CodeArt.
Вот ссылки на все публикации этой серии по мере их публикации:
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
«Наверное, мне следует построить свой собственный [insert big side project here]» руки вверх — как часто вы задумывались об этом, находясь в середине реализации? Чаще всего это мои предположения, судя по всем новым разработкам и всем строкам кода, которые я вижу в каждой реализации, на которую смотрю.
И я это понимаю. Я также люблю изобретать что-нибудь — на самом деле, если вы пролистаете мой блог, вы увидите множество доказательств этого.
Но вспомните номер 8 в нашем списке 12 лучших: Рождественский обратный отсчет: #8 Сопровождение кода — 90% работы, и вы, возможно, еще раз подумаете, не пришло ли время заново изобрести велосипед. Фактически, в большинстве случаев, когда нам хочется создать огромный побочный проект с нуля, это уже решенная проблема — либо в базовой CMS, либо в лучших практиках, либо в популярном дополнении, либо в стороннем продукте.
И если вам повезет, вы можете принять это решение и либо использовать его как есть, либо, возможно, немного расширить его, чтобы оно соответствовало вашим конкретным потребностям.
Некоторые вещи, с которыми я часто сталкиваюсь в нестандартных реализациях, заставляют меня задуматься:
- Таможенная коммерция. Иногда на базе CMS вместо использования EPiServer Commerce создается полноценная торговая платформа, изготовленная на заказ.
- Пользовательские теги рендеринга. Возможно, рендеринг тегов — менее известная функция CMS — нередки изобретения новых способов управления различными рендерингами одного и того же контента.
- Пользовательский конвертер изображений. В настоящее время стандартными являются преобразования ImageSharp или прямые преобразования Cloudflare. Но я все еще вижу много других конвертеров изображений.
- Генераторы пользовательских карт сайта
- Пользовательский API для отдыха. Такое я вижу очень часто на headless-решениях — по каким-то причинам почти никто не будет использовать Content Delivery API.
- Пользовательские формы. Есть вполне хорошие формы Episerver — но нет, давайте придумаем что-нибудь, что делает то же самое, но гораздо более сложным образом, требующим большого количества кода.
Когда я сталкиваюсь с пользовательским кодом, подобным приведенному выше, пытаюсь понять, почему. И зачастую это своего рода детективная работа. Могут существовать вполне веские и законные причины, такие как:
- Исторический: хорошего решения в то время не существовало.
- Юридические/политические причины и требования
- Стоимость решения по сравнению с решением, построенным дома (хотя обычно кто-то забывает учесть будущие затраты на техническое обслуживание)
Но есть и множество плохих причин, которые на самом деле являются лишь симптомами синдрома «изобрето не здесь».
- Не зная, что существует стандартизированное решение
- Оцененные и стандартизированные решения не отвечали конкретным потребностям. Но помните, что их обычно можно отрегулировать. Или как насчет разветвления репозитория, улучшения кода и проведения пиара — таким образом вы внесете свой вклад в мир, при этом используя несколько стандартизированный код.
- Привязка к агентству (когда агентство по внедрению хочет убедиться, что клиент не сменит поставщика, чтобы они зависели от собственного кода, а не от клиента).
- Младшие разработчики, желающие писать код и создавать с нуля.
NIHS опасен и в долгосрочной перспективе может оказаться невероятно дорогим в обслуживании.