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

Question

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

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

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

Answer 1

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

Основы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Избегает ли код ввода пользователем?

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

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

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

Итог:

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

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

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

Answer 2

Некоторые красные флаги "плохой практики", характерные для Magento, следующие:

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

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

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

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

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

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

Answer 3

Шаг № 1 — Может ли ваш клиент позволить себе поддерживать это расширение, если разработчик уйдет в самоволку?

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

Вы правы.

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

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

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

Answer 7

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

Answer 8

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

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

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

PCI-DSS v3

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

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

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

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