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

Question

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

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

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

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

41

performance extensions

Author: Roger Herbert, 2013-01-31

Source

8 answers

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

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

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

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

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

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

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

10

Author: Fabian Schmengler, 2013-01-31 19:14:16

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

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

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

4

Author: Brendan Falkowski, 2013-01-31 19:32:11

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

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

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

2

Author: Tyler Hebel, 2013-01-31 15:06:45

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

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

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

1

Author: xyphoid, 2013-01-31 22:36:21

Вы правы.

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

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

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

0

Author: Sylvain Rayé, 2013-01-31 15:00:43

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

0

Author: Alessandro Ronchi, 2013-01-31 15:52:04

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

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

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

PCI-DSS v3

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

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

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

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

0

Author: Luke A. Leber, 2020-06-15 08:30:17

score 27 · Accepted Answer

Вот некоторые соображения по оценке сторонних модулей:

Основы:

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

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

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

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

Прочитав в обзорах мы можем лучше понять общую картину, есть ли проблема с установкой? Отвечают ли разработчики своевременно и полезно? Работает ли это так, как рекламируется?
Возврат средств - Вернут ли они вам ваши деньги, если все пойдет не так, как задумано?

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

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

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

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

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

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

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

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

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

Продвинутый:

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

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

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

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

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

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

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

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

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

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

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

Итог:

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

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

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