Как оценить сторонние расширения?

В то время как Magento делает многое «из коробки», мы обнаружили, что неизбежно существуют функции и возможности, необходимые для клиентских магазинов, которые требуют стороннего расширения.

Однако, учитывая природу среды, может быть рискованным предложение ввести «чужой» код в такую ​​сложную систему, имеющую дело с коммерческими транзакциями.

Что вы ищете при оценке расширений Magento? С какими «красными флагами» вы столкнулись (скачки производительности, риски безопасности, плохие архитектурные решения)?

Вот несколько советов по оценке модулей сторонних производителей:

Основы:

• Поддержка текущей версии Magento - Поддерживает ли она последнюю версию Magento (включая текущую версию, для которой мы ее разрабатываем)?

  Если модуль не поддерживает последнюю версию Magento, возможно, будет трудно заставить его работать, не тратя на него драгоценное время разработки.

• Поддержка - Поддерживают ли разработчики, создавшие модуль, продукт?

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

  Кроме того, когда модуль поддерживается, мы обычно можем получить важную информацию от разработчиков по простой электронной почте (например, использует ли этот модуль jQuery или Prototype).

• Отзывы - Что говорят другие пользователи? Как прошел их опыт?

  Читая обзоры, мы можем лучше понять общую картину, есть ли проблема с установкой? Отвечают ли разработчики своевременно и полезно? Это работает как рекламируется?

• Возврат денег - вернут ли вам ваши деньги, если они не сработают, как задумано?

  Много раз мы хотели опробовать модуль, чтобы мы могли его протестировать, если он работает и отвечает нашим требованиям! Но если этого не произойдет, мы хотим вернуть его и получить за него деньги.

Промежуточное:

• Переопределение классов - переопределяет ли модуль какие-либо основные классы?

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

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

  Иногда это невозможно сделать, если это так, должна быть очень веская причина, по которой он переопределяет основной класс.

• Обновления макета - Изменяет ли модуль некоторые из моих настроек макета?

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

• Изменения шаблонов. Включает ли модуль шаблоны, которые меняют мой текущий дизайн?

  Будет ли этот модуль вводить новые шаблоны? Если да, сломают ли они мой дизайн? Сколько времени потребуется, чтобы дизайн был таким, каким мы хотим?

• Зависимости - зависит ли модуль от любого другого модуля?

  Если модуль зависит от других, мы должны убедиться, что они есть и установлены. Кроме того, мы должны спросить себя, хотим ли мы в будущем отключить модуль, от которого он зависит?

Дополнительно:

• Сценарии обновления SQL - обновляет ли модуль каким-либо образом БД?

  Как только модуль обновляет базу данных, нам нужно убедиться в нескольких вещах.

  Обновляет ли это базовую таблицу? Если да, это не хорошо, нам нравится, что наши базы данных чистые и готовы к обновлению.

  Хранит ли она информацию разумным способом? Если мы хотим сами получать данные из базы данных, сможем ли мы понять это?

• События - наблюдает ли модуль или отправляет какие-либо события?

  Если модуль отправляет или наблюдает за событиями, мы хотим знать:

  Какие события он наблюдает / рассылает? Повлияет ли это на другой модуль, работающий в системе. Например, если один из наших модулей изменит название загружаемого продукта на верхний регистр, и этот модуль добавит слово «свободный» к названию загружаемого продукта, как он будет работать? Будет ли слово «свободный» также в верхнем регистре?

• Проверка кода - Использует ли модуль приемлемые методы кодирования?

  Это больше связано с методами кодирования PHP, чем с Magento.

  Использует ли код блоки Try / Catch?

  Код экранирует пользовательский ввод?

  Особенности этого действительно зависят от нашего уровня квалификации / требований.

• Потенциальные проблемы - Какие потенциальные проблемы могут возникнуть в результате установки этого модуля?

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

Нижняя граница:

Все эти вещи приятно иметь в идеальном мире, в реальных сценариях нам нужно делать то, что называется «компромисс» :)

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

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

Некоторые специфичные для Magento красные флаги "плохой практики":

• любой код в app/code/local/Mage
• перезаписанные шаблоны (файлы в app/designкоторых уже есть в ядре)
• переписывает основные классы, как catalog/product. В общем, я внимательно слежу за каждым переписыванием, чтобы увидеть, можно ли его избежать
• серьезные нарушения стандартов кодирования Zend / Magento. Хотя речь идет только о форматировании кода, я прихожу к выводу, что разработчики, которые не заботятся о стандартах, скорее всего, будут также не заботиться о других, более важных вещах.
• изменения в основных таблицах базы данных
• жестко закодированный текст в шаблонах (без использования механизма перевода) и в других местах
• бизнес-логика в шаблонах (практическое правило: любое вхождение Mage::getModelв каталог шаблонов обычно является плохим признаком)

Некоторые связанные с PHP красные флаги (это очень выборочный и неполный список):

• любые уведомления и предупреждения с включенным отчетом об ошибках ( E_STRICT)
• использование @оператора
• не очищать пользовательские данные перед выводом

Некоторые связанные с производительностью красные флаги:

• запросы к базе данных внутри циклов
• загрузка всей коллекции только для того, чтобы использовать ее часть

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

Шаг № 1 - Может ли ваш клиент позволить себе поддержку этого расширения, если разработчик выходит из AWOL?

Если нет, вы не можете использовать расширение.

Если да, перейдите к оценке продления.

У хороших людей в Inchoo есть статья об анализе кода сторонних модулей. В статье упоминается переписывание классов, задания cron, обновления макетов и наблюдатели событий.

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

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

Наличие каких-либо шаблонов и ресурсов скина, расположенных в default / default (или pro или enterprise) вместо base / default, довольно раздражает.

Запутанный код - это то, на что нужно обратить внимание - ищите вызовы eval (), base64_decode () и тому подобное. Это часто используется для проверки лицензии, но может быть злонамеренным или пугающим - я видел по крайней мере один компонент, который eval'd произвольный код из RSS-канала.

Ищите вызовы dl () - по крайней мере, один компонент платежного шлюза, который я видел, требует установки расширения PHP для его соединений!

Вы правы.

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

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

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

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

Тест № 1, который я могу придумать, состоит в том, чтобы найти эксплойт нулевого дня в их коде (обычно это не очень сложно с расширениями Magento), сообщать только о полученном уроне фиктивного эксплойта их команде безопасности (не указывая, какой часть кода уязвима), и запустите секундомер - потому что это именно то, что произойдет, когда ваш сайт будет взломан. Когда их сотрудники службы поддержки запрашивают глобальный доступ по FTP и mysql, вежливо отказываются, заявляя, что это является нарушением PCI-DSS, и предлагают им иметь доступ только для чтения к вашему хранилищу исходного кода.

Тест №2, который я выполняю, состоит в том, чтобы позвонить продавцу и застать его врасплох. Спросите их, какой тип поведенческого / модульного тестирования они проводят, какую систему контроля версий они используют, какие версии PHP они тестируют, какие версии Magento тестируются, какие веб-серверы тестируются, используют ли они браузер или нет -стек для тестирования интерфейсных компонентов и т. д. Если поставщик не знает, о чем вы говорите, замолкает или хочет «заставить эксперта отправить вам электронное письмо», бегите как в аду, потому что он, скорее всего, использует нумерованный zip-файлы для «контроля версий» и исправления ошибок только через 3 месяца после того, как их клиенты сообщат о них.

Говоря о PCI-DSS, все модификации системы также должны иметь стратегию возврата. С модулями, которые добавляют необнуляемые столбцы в основные таблицы, это становится почти невозможным, при этом сохраняя стратегию возврата, которая прошла бы аудит. Запускается как в аду из любых модулей, которые при отключении вызывают проблемы (читай: ошибки SQL).

PCI-DSS v3

6.4.5.4 Процедуры возврата.

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

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

Это, в дополнение к другим ответам. ИМО должна быть стена позора для некоторых опасных дерьма, которые появились на этой платформе.